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ABSTRACT 


This handbook of Air Force automatic data processing experience 
is a pilot version of one to be produced in the next phase of the project. 
The ADP experience data was collected by interview on 18 Air Force 
ADP systems; the handbook produced during the next phase of the proj¬ 
ect will be updated from experience periodically reported to Headquar¬ 
ters, USAF, from some 200 ADP systems. The purpose of the pilot 
version is to acquaint Air Force personnel with the concept of using 
highly organized, summarized, and retrievable ADP experience in judg- 
ing proposals for new automation. The pilot version of the handbook 
contains data collected after the fact from only 18 ADP systems, and 
hence the handbook has limited usefulness for actual evaluation of ADPS 
proposals. It does, however, contain cost estimation equations and nar¬ 
rative experience that will be useful until the 200 system handbook can 
be produced in Phase III. 

Experience relevant to a proposed ADPS is retrieved from the hand¬ 
book via information extracted from the proposal. The extracted infor¬ 
mation consists of quantitative workload descriptors of the proposed 
ADPS (e. g. , number of input data fields and number of output formats) 
and certain qualitative descriptors (e. g. , centralized or decentralized 
operations and presence or absence of direct access storage). The quan¬ 
titative workload descriptors are used with cost estimation iso-graphs 
in the handbook to predict costs, so that proposed cost factors (e. g. , 
man-months of development effort and dollars per month of hardware 
cost for application production) may be compared with Air Force ex¬ 
perience. Both quantitative and qualitative descriptors are used to re¬ 
trieve relevant information from the 18 system descriptions found in the 
handbook. The retrieved experience will be used to check consistency 
and to uncover potential problems of the proposed ADPS that may be en¬ 
countered during system development and operation. 

A primer on the use of this handbook applied to a hypothetical ADPS 
proposal is published separately as ESD-TR-66-672. A final report cov¬ 
ering activities and conclusions of the project is also published sepa¬ 
rately as ESD-TR-66-671. 
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I. USE OF EXPERIENCE HANDBOOK 


The Experience Handbook is used to evaluate a proposed ADPS in 
two major steps. The first step involves the comparison of proposed 
cost factors such as man-months of development effort with estimated 
cost factors obtained through use of cost estimation iso-graphs. These 
iso-graphs are graphical representations of cost estimation equations 
derived from sampled data on 18 Air Force ADP systems. Subsection 
I. A. describes the use of these iso-graphs. 

The second step for use of the handbook involves reviewing the 
proposed hardware, software, development plan, file conversion plan, 
etc. , in light of experience gained by the Air Force in the development 
and operation of 18 ADP systems. The experience information is re¬ 
trieved from 18 system descriptions through the use of 12 indexes. 
Subsection I.B. describes the use of these indexes for retrieval of ex¬ 
perience information, while subsection I. C. describes the format and 
content of the experience information in the system descriptions. 

A. Cost Estimation 


1. Description of Iso-Graphs 

Five sets of iso-graphs representing the five cost estimation 
equations and their respective intervals are available for cost estimation. 
These sets of iso-graphs are identical in structure and are contained in 
Section II. Each set is used for determining three expected values for a 
cost factor. Cost factors that may be estimated are as follows: 

Development Cost 


o Man-months of development effort 
Operations Cost 


o Number of program maintenance personnel 

o Number of operations personnel 

o Dollars per month of hardware cost for application production 

o Dollars per month of hardware cost for program maintenance 

The workload descriptors from the ADPS proposal are used for de¬ 
termining cost from the iso-graphs. The workload descriptors required 
for using all five sets of iso-graphs are as follows: 

Input Variables 

o Characters per month of input volume 
o Number of input data fields 
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Output Variables 


o Characters per month of output volume 
o Number of output formats 

Data Base Variable 


o Characters in data base 

See Figure 1 for an example of a set of iso-graphs. The set con¬ 
tains three charts, each to be entered in identical fashion. The hori¬ 
zontal scale of the example marks off the number of input data fields, 
while the vertical scale marks off the number of output formats. 

2. Obtaining the Cost Estimates 

Follow the procedure of steps a through g to obtain the three 
values of a cost factor. 

a. Find the workload descriptor value for the proposed 
ADPS on the horizontal scale of any one of the three 
iso-graphs. 

b. Draw a vertical line through all three iso-graphs at 
the value established in step a. 

c. Find the workload descriptor value for the proposed 
ADPS on the vertical scale of each of the three 
iso-graphs. 

d. Draw a horizontal line on all three iso-graphs through 
the values established in step c. 

e. On the top iso-graph, determine the value that the cost 
estimate is expected to be less than, 90 percent of the 
time, by logarithmically interpolating the intersection 
point of the vertical (step b) and horizontal (step d) 
lines between adjacent iso-lines. 

f. On the center iso-graph, determine the value that the 
cost estimate is expected to be, by logarithmically 
interpolating the intersection point of the vertical 
(step b) and horizontal (step d) lines between adjacent 
iso-lines. 

g. On the bottom iso-graph, determine the value that the 
cost estimate is expected to be greater than, 90 percent 
of the time, by logarithmically interpolating the inter¬ 
section point of the vertical (step b) and horizontal 
(step d) lines between adjacent iso-lines. 
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FIGURE 1 - COST ESTIMATING ISO-GRAPH FOR MAN-MONTHS OF DEVELOPMENT EFFORT 

















































































































































































































































































































































































3. Interpreting the Results 


The results taken from the three iso-graphs have the follow¬ 
ing meaning: 

Top Iso-Graph Iso-lines of this chart give the value the estimated 
cost factor is expected to be less than, 90 percent of the time. 

Center Iso-Graph Iso-lines of this chart give the value the cost 
factor is expected to be (50 percent of the time it will be greater 
and 50 percent of the time it will be smaller). 

Bottom Iso-Graph Iso-lines of this chart give the value the cost 
factor is expected to be greater than, 90 percent of the time. 

4. Using Estimated Costs and Relevant Experience 

The proposed costs are compared with estimated costs 
from the top and bottom iso-graphs to determine whether the pro¬ 
posed costs fall within their respective prediction intervals.* If 
any of the proposed costs are outside their respective prediction 
intervals, these costs are highly suspect of error and should be 
carefully examined using relevant experience data retrieved from 
system descriptions in the handbook. If the proposed costs are 
within their predicted intervals, relevant experience data are re¬ 
trieved from the system descriptions to verify the reasonableness 
of the proposed costs. 

B. Retrieval of Relevant Experience 

Twelve indexes are available for retrieving information from the 
18 system descriptions. The system descriptions appear in Section III 
and indexes in Section V. Two of the indexes use workload descriptors 
for retrieval of experience, while the other 10 use other system attri¬ 
butes such as functional area. The 12 indexes do not exhaust all attri¬ 
butes for indexing, but provide convenient tools for retrieving the bulk 
of experience data in the system descriptions relevant to a proposed 
system. This section describes the manual procedures for retrieving 
information relevant to a proposed ADPS using each of the 12 indexes. 

1. Development Experience Index 

The Development Experience Index uses a Development Ex¬ 
perience Index Worksheet (see Section V) in conjunction with a plastic 
index card. The index card is also used with the Operations Experience 
Index. Figure 2 illustrates the parts of the index card. 


The prediction intervals for the cost estimation equations in this pilot 
version of the Experience Handbook are rather wide. These wide inter¬ 
vals are largely due to the small sample size used in development of 
these equations. 
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FIGURE 2 - PARTS OF THE INDEX CARD 



















































To determine systems which have relevant development experi¬ 
ence, fill out a Development Experience Index Worksheet according to 
the following procedures (also included on the worksheet): 

a. Enter the proposed values for No, of Input Transac¬ 
tion Types, No. of Input Data Fields, No. of Output 
Formats, and No. of Data Base Record Types in box 
below the corresponding scale. 

b. Remove the index card from the pocket and position 
the center arrow of the Development Slide at the pro¬ 
posed value on the No. of Input Transaction Types 
scale. 

c. For all systems bounded by the Development Slide, 
enter the number from the tolerance band in the No. 
of Input Transaction Types row of the Ranking Table 
beneath the corresponding system name. 

d. Repeat steps b and c for No. of Input Data Fields and 
No. of Output Formats. 

e. Repeat steps b and c for No. of Data Base Record 
Types if the proposed value is not zero. If the pro¬ 
posed No. of Data Base Record Types is zero, enter 
the number 3 in the Data Base row of the Ranking 
Table beneath ADOBE, MISSIM, and ORBIT. 

f. Enter the Total Rank in the bottom row of the Ranking 
Table. Total Rank is computed by adding the numeric 
entries in each column of the Ranking Table. 

g. The system with the largest Total Rank is the most 
relevant system in developmental aspects to the pro¬ 
posed system. Relevancy of other systems is in order 
of Total Rank. Systems with Total Rank equal to or 
greater than 7 are highly relevant to the proposed au¬ 
tomation. Systems with Total Rank less than 7 but 
greater than 3 have less relevance, but may still be 
used, while developmental experience data from sys¬ 
tems with Total Rank less than or equal to 3 should 
not be used. 

2. Operations Experience Index 

The Operations Experience Index uses an Operation Experience 
Index Worksheet (Section V) in conjunction with the same plastic index 
card used for the Development Experience Index. See Figure 2 for defi¬ 
nition of index card parts. 
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To determine systems that have relevant operations experience, 
fill out an Operations Experience Index Worksheet according to the fol¬ 
lowing procedures (also included on the worksheet): 

a. Enter the proposed values for Char, /Mo, of Input 
Volume, Char. /Mo. of Output Volume, and Char, 
in Data Base in the box below the corresponding 
scale. 

b. Remove the index card from the pocket and position 
the center arrow of the Operations Slide at the pro¬ 
posed value of the Char. /Mo. of Input Volume scale. 

c. For all systems bounded by the Operations Slide, 
enter the number from the tolerance band in the 
Char. /Mo. of Input Volume row of the Ranking 
Table beneath the corresponding system name. 

d. Repeat steps b and c for Char. /Mo. of Output Volume. 

e. Repeat steps b and c for Char, in Data Base, if the 
proposed value is not zero. If the proposed Char, in 
Data Base is zero, enter the number 3 in the Data 
Base row of the Ranking Table beneath ADOBE, 
MISSIM, and ORBIT. 

f. Enter the Total Rank in the bottom row of the Ranking 
Table. Total Rank is computed by adding the numeric 
entries in each column of the Ranking Table. 

g. The system with the largest Total Rank is the most 
relevant system in operational aspects to the pro¬ 
posed system. Relevancy of other systems is in order 
of Total Rank. Systems with Total Rank equal to or 
greater than 5 are highly relevant to the proposed sys¬ 
tem. Systems with Total Rank less than 5 but greater 
than 2 have less relevance, but may still be used, 
while operational experience data from systems with 
Total Rank less than or equal to 2 should not be used. 

3. Functional Area Index 


The Functional Area Index is used to retrieve systems with 
the same functional area as the proposed ADPS. All sampled ADP sys¬ 
tems fall into one of the following functional areas: 

o Operations Supporting 

o Research and Development 

o Materiel Management 

o Personnel Manpower 
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o Financial and Accounting 
o Weather 

o Transportation Management 

o Miscellaneous 

To use this index, find the row of the Functional Area Index Table 
(Section V) with the same functional area as the proposed ADPS. An 
"X" will appear in this row under each sampled ADPS with the same 
functional area. 

4. Decentralized Operations Index 

Decentralized operations imply that an ADPS has a centralized 
development with a number of decentralized operations dependent on the 
centralized development for system maintenance and support as well as 
delivery of the initial system capability. The Decentralized Operations 
Index is used to retrieve systems with the number of operational instal¬ 
lations in the same range as the number of operational installations of 
the proposed system. Sampled ADP systems are divided into groups 
according to the following criteria: 

o Single Operational Installations 

o From 2 to 7 Operational Installations 

o From 8 to 100 Operational Installations 

o More than 100 Operational Installations 

To use this index, find the row of the Decentralized Operations 
Index Table (Section V) corresponding to the number of operational in¬ 
stallations for the proposed ADPS. An "X" will appear in this row under 
each sampled ADPS with the number of operational installations in the 
same range. 

5. Multiple Application Index 

"Multiple applications" refers to the operation of more than 
one ADPS at a given computer installation. The Multiple Applications 
Index is used to retrieve systems with the number of applications on an 
installation in the same range as the number of applications of the pro¬ 
posed system. Sampled ADP Systems are divided into groups according 
to the following criteria: 

o Single Application at an Installation 

o From 2 to 10 Applications at an Installation 

o More than 10 Applications at an Installation 

To use this index, find the row of the Multiple Application Index 
Table (Section V) corresponding to the number of applications at an in¬ 
stallation for the proposed ADPS. An "X" will appear in this row under 
each sampled ADPS with the number of applications in the same range. 
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6. Programming Language Index 


Programming languages include procedure-oriented lan¬ 
guages, assembly languages, and the lack of any language usage (ma¬ 
chine language). The Programming Language Index is used to retrieve 
systems using the same type of programming language in their develop¬ 
ment as the proposed ADPS. 

To use this index, find the row of the Programming Language Index 
Table (Section V) with the same programming language specified for the 
proposed ADPS, An "X" will appear in this row under each sampled 
ADPS using the same programming language as the proposed system. 
Since more than one programming language may be used in a system de¬ 
velopment, the same procedure may be repeated to retrieve systems 
using all programming languages planned for use in the proposed ADPS. 

7. Processing Type Index 

The Processing Type Index is used to retrieve systems with 
the same type of processing control specified for the proposed system. 
The processing types are defined by the following criteria. 

o Real-time data collection 

o On-line inquiry processing 

o Batched processing under executive control 
o Batched processing with no executive control 

To use this index, find the row of the Processing Type Index Table 
(Section V) corresponding to the processing type of the proposed ADPS. 
An "X" will appear in this row under each sampled ADPS with the same 
processing type. 

8. File Conversion Index 

The File Conversion Index is used to retrieve systems with 
types of file conversion similar to the proposed system. Types of file 
conversion are defined by the following criteria: 

o No file conversion 

o Conversion from manual to ADP system 

o Conversion from PCAM to ADP system 

o Conversion from ADP to ADP system 

To use this index, find the row of the File Conversion Index Table 
(Section V) corresponding to the type of file conversion for the proposed 
ADPS. An ,f X" will appear in this row under each sampled ADPS with 
the same type of file conversion. 
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9. 


Direct Access Storage Index 


The Direct Access Storage Index is used to retrieve systems 
with an amount of direct access storage in the same range as the direct 
access storage for the proposed system. Sampled ADP Systems are di¬ 
vided into groups according to the following criteria: 

o No direct access storage 

o Less than 10 million characters 

o From 10 million to 50 million characters 
o Greater than 50 million characters 

To use this index, find the row of the Direct Access Storage Index 
Table (Section V) corresponding to the amount of direct access storage 
for the proposed ADPS. An "X" will appear in this row under each sam¬ 
pled ADPS with amount of direct access storage in the same range. 

10. Computer Cost Index 

This index is used to retrieve systems with computers of 
approximately the same basic monthly rental cost as the proposed ADPS. 

If a proposed value for basic monthly rental (for all applications) is avail¬ 
able, systems with approximately the same cost may be located by search¬ 
ing for rows with the closest value of basic monthly rental. An "X" will 
appear under each sampled ADPS with the same value of basic rental cost. 

11. Computer Index 


The Computer Index is used to retrieve systems using the 
same computer as the proposed ADPS. In the event that a proposed sys¬ 
tem does not specify the computer to be used, this index will not be 
applicable. 

To use this index, find the row of the Computer Index Table (Sec¬ 
tion V) with the proposed computer. An "X" will appear in this row under 
each sampled ADPS using the same computer. If the proposed ADPS has 
more than one computer model, such as a base computer and peripheral 
computer, each computer must be looked up individually in the Computer 
Index Table. Systems using both the proposed base and the peripheral 
computers should be used in preference to systems using the base or 
peripheral computers individually. 

12. Security Index 

The Security Index is used to retrieve systems with the same 
security classification as the proposed system. Security classifications 
may apply to any one or all of the following system aspects: 

o Inputs 

o Data base 

o Output 
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o System design and programs 

o Hardware 

Sampled ADP systems are divided into four groups according to 
the following criteria: 

o No aspect of system is classified 

o Some aspect of system is Confidential 

o Some aspect of system is Secret 

o Some aspect of system is Top Secret 

To use this index, find the row of the Security Index Table with the 

highest classification of data to be found in the proposed ADPS. An M X M 
will appear in this row under each sampled ADPS with the same level of 
security classification. 

C. Evaluation of Relevant Experience 


After the names of relevant systems have been determined through 
indexing, as described in subsection I. B, the next step is to examine the 
system descriptions for relevant experience information. Table 1 en¬ 
ables one to quickly determine which sections of a system description 
will contain experience information for a given index. An index may 
select a large number of systems on a specific attribute, such as the 
use of COBOL. To reduce the number of systems examined, exclude 
systems first on the basis of different functional areas and then on the 
basis of a low ranking of the Development and Operations Experience 
Indexes. Subsections I.C. 1 through I.C.21 describe the format and 
content of sections in the order in which they appear in the system de¬ 
scription, and also specify their use in evaluation of experience data. 

1. System 

This section of a system description identifies the ADPS by 
its title, the computer designation(s), and the acronym used for refer¬ 
ence throughout the handbook. The acronym is repeated at the top of 
each page of the system description. 

2. Data System Designator 

This section of a system description identifies the ADPS by 
the USAF Data Systems Automation Program (DSAP) code. 

3. Data Collection Date 


This section of a system description identifies the month 
and year in which the data collection occurred for the ADPS. 

4. Location 


This section of a system description identifies the office and 
address to contact for more detailed information on the ADPS. This 
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TABLE 1 - RELEVANT SYSTEM DESCRIPTION SECTIONS RETRIEVED BY INDEXES 


Sections of System 
Description 

Name of 

Index N. 

Location 

Function 

Organization 

History 

Schedule 

Description 

Workload 

Hardware 

Software 

Application 

Program 

Development 

File 

Conversion 

Documentation 

Personnel 

Operations 

Application 

Program 

Maintenance 

Benefits 

Cost 

Factors 

Future 

Plans 

Development Experience 



R 

R 

H 

R 



R 

H 

R 

R 

R 


H 

R 

R 


Operations Experience 



R 



R 


H 

R 


R 

R 

R 

H 


R 

R 


Functional Area 


H 




H 




R 

R 


R 


R 

R 



Decentralized Operations 

H 


R 

H 

H 

R 


R 


H 


R 

R 


H 

R 

R 


Multiple Application 



R 






R 





H 





Programming Language 






R 


R 

H 

H 



R 


H 

R 



Processing Type 






H 

R 

H 

H 

R 




R 



R 


File Conversion 




R 

R 


R 

R 



H 






R 


Direct Access Storage 






R 


H 

R 

R 




R 

R 




Computer Cost 




R 

R 


R 

H 

R 





H 



R 


Computer 




R 

R 


R 

H 

R 

R 

R 



H 

R 


R 


Security 
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Notes: H indicates a highly relevant section. 
R indicates a relevant section. 



































section also identifies the location of development, location of mainte¬ 
nance, location of pilot installation, location of first operational instal¬ 
lation, and the number of operational installations. 

5. Function 


This section of a system description identifies the primary 
user(s) and briefly describes the AF mission being supported by the 
ADPS and the functions performed by the system in support of the 
mission. 

6. Organization Chart 

This section of a system description identifies the ADPS or¬ 
ganizational designator(s), developer(s), user(s), and operator(s) and 
the relationships between them. Whenever possible, the general orga¬ 
nizational framework shown in Figure 3 has been adhered to. 

A brief commentary follows the chart, when appropriate, in an 
attempt to explain special actions taken in organizing the effort and the 
ramifications of these actions on system development and operation. 

7. History 

This section of a system description briefly describes any 
systems related to the ADPS that may have contributed to its develop¬ 
ment. Proposals and/or directives effecting the system development 
of the ADPS and significant milestones are identified. 

8. Schedule 


This section of a system description displays a schedule 
showing all known proposed and actual dates that may be significant to 
the development and operation of the ADPS. The schedule identifies 
the actual development and operational phases of the ADPS. 

9. Description 

This section of a system description identifies and describes 
the processing functions performed by the ADPS. The orientation is 
toward the functional characteristics of the system rather than the data 
processing characteristics. The section begins with a narrative descrip¬ 
tion of the system, including descriptions of any unusual communication 
capabilities used to get input to the system and output to the user. The 
above is accompanied by the system flow chart(s) for the ADPS. The 
system flow chart(s) contain several or all major processes of the sys¬ 
tem at a macro level. 
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FIGURE 3 - LEVELS OF ORGANIZATION 
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Workload 


This section of a system description identifies the magnitude 
of the ADPS workload through an information flow diagram. The diagram 
is composed of four major areas: (1) inputs, (2) data base, (3) process¬ 
ing functions, and (4) outputs. These areas are broken down as follows: 

a. Inputs 

(1) Characters per month of input volume 

(2) Number of input transaction types 

(3) Number of input data fields 

(4) Percent of input rejects 

b. Data Base 

(1) Characters in data base 

(2) Percent of characters on direct access (D/A) 
storage 

(3) Milliseconds of access time for D/A 

(4) Number of data base record types 

(5) Number of data base records 

(6) Percent growth rate per month 

(7) Characters per month of update input 

c. Processing Functions 

(1) A vertical bar graph is used to display the per¬ 
centage breakdown of source instructions and 
hours of application production by the following 
processing categories: 

(a) Input edit 

(b) File maintenance 

(c) Query 

(d) Sort 

(e) Merge 

(f) Compute 

(g) Report generation 

(h) Control 

(2) The following quantities are shown both for the 
base computer(s) and for the peripheral 
computer(s): 

(a) Source instructions 

(b) Object instructions 

(c) Hours per month of application production 
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d. Outputs 


(1) Characters per month of output volume 

(2) Number of output formats 

(3) Response time (seconds), if on-line system 
11. Hardware 


This section of a system description identifies and describes 
the hardware used by the ADPS. The section is composed of two major 
areas: (1) a hardware configuration chart and (2) a hardware specifi¬ 
cations table. 


a. The configuration chart indicates model numbers and 
hardware interconnection of components for all computers in the system 
by charts such as that shown in Figure 4. 

b. The specifications table is not a rigid format; it only 
includes specifications for hardware present in the system. Whenever 
required, the table includes the following: 


(1) Computer model number 

(2) First delivery date (month/year) 

(3) Word or character machine 

(4) Add time (in microseconds) 

(5) Internal storage 

(a) Effective cycle time (in microseconds) 

(b) Word or character size 

(c) Storage capacity in words or characters 

(6) External storage 


(a) Magnetic tapes 


o Model number 

o Transfer rate 


(b) Disk 

o Model number 

o Transfer rate 

o Capacity (in characters) 

o Access time (in milliseconds) 


(c) Drum 

o Model number 

o Transfer rate 

o Capacity (in characters) 

o Access time (in milliseconds) 
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FIGURE 4 - SAMPLE CONFIGURATION 























































































































(7) Peripheral devices 

(a) Card Reader 

o Model number 

o Speed (in full 80 char, cards per 

minute) 

(b) Card Punch 

o Model number 

o Speed (in full 80 char, cards per 

minute) 

(c) Printer 

o Model number 

o Speed (in lines per minute) 

(d) Paper Tape Reader 

o Model number 

o Speed (in characters per second) 

(e) Paper Tape Punch 

o Model number 

o Speed (in characters per minute) 

(f) Communications 

o Lines in multiplexer 

o Auto-dial 

o Number of consoles attached 

o Class of service 

(g) Miscellaneous Devices 

A commentary follows to indicate unusual hardware problems, 
conditions requiring hardware modification, redundancy or backup capa¬ 
bility, and characteristics from the chart or table requiring explanation. 

12. Software 


This section of a system description identifies and describes 
the support software (i.e. , compilers, assemblers, executives, etc.) used 
as tools in developing and operating the application programs of the ADPS. 

A commentary follows, when appropriate, in an attempt to indi¬ 
cate slippages in delivery, problems encountered in software usage, 
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special attributes that significantly assisted development and/or opera¬ 
tion, and software maintenance support. 

13. Application Program Development 

This section of a system description describes the signifi¬ 
cant activities affecting development of the application programs for the 
ADPS. Included in the section are descriptions of logic definition, inter¬ 
action between analysts and programmers, programming techniques, 
and type and extent of program and system testing. 

A commentary follows, when appropriate, in an attempt to describe 
any conditions existing during the development phase of the ADPS that 
may have affected the development of the application programs. 

14. File Conversion 


This section of a system description describes the type and 
extent of file conversion activities required by the ADPS. Included in 
the section are descriptions of the format of data prior to conversion, 
the method of conversion, any special programs required for the con¬ 
version, quality control techniques employed in making the conversion, 
and hours of computer use required for conversion. 

15. Documentation 

This section of a system description lists all AFM's, AFR's, 
OI ! s, etc. , documenting the ADPS. Included are descriptions of any 
other types of documentation and past, present, and future efforts to 
document the ADPS during development and operation. Comments are 
made regarding the completeness and usability of documentation when 
appropriate. 

16. Personnel 


This section of a system description describes the person¬ 
nel involved with the ADPS through the use of a personnel table. The 
table indicates the following for managers, analysts, and programmers 
of the development phase, and for managers and operators of the oper¬ 
ational ADPS: 

a. Number of People 

(1) Sampled 

(2) Allocated to the system 

b. Number of Years 

(1) In ADP 

(2) In functional area 

(3) Of college 
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17. Operations 


This section of a system description begins with a brief nar¬ 
rative description of the operation of the ADPS. 

Pie chart representations of the computer utilizations are displayed 
for each different computer used by the ADPS. For multi-installation 
systems, computer utilization data is taken from one typical installation. 
The pie charts use the following classifications of time: 

a. For the subject ADPS or application 

(1) Production time 

(2) Preparation time 

(3) Program development and maintenance 

b. For all other applications 

(1) Production time 

(2) Preparation time 

(3) Program development and maintenance 

c. Chargeable lost time (by application if possible) 

d. Set Up time 

e. Idle time 

f. Unscheduled maintenance time 

g. Machine error lost time 

h. Scheduled maintenance time 

i. Off time 

j. Other time 

Each pie chart uses 7 30 hours as the total available number of 
hours per month. This total number is exactly one twelfth of the num¬ 
ber of hours in a 365-day year. The actual number of hours used dur¬ 
ing a 31-day (744-hour) or 30-day (720-hour) month was prorated to 
the 730-hour standard used in the pie charts. 

The operations section ends with a brief commentary, when appro¬ 
priate, in an attempt to clarify any apparent or hidden reasons for un¬ 
usual utilization activity or lack of activity displayed in the pie charts. 
The commentary also notes any other unique operational characteristics 
of the computer installation as a whole. 

18. Application Program Maintenance 

This section of a system description describes the effort, 
techniques, and organization for all maintenance and continuing devel¬ 
opment activities to application programs after the system was declared 
operational. Included in the section, when available, are indications of 
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relative efforts for program corrections as opposed to improvements 
or new development, and what portion of the program maintenance per¬ 
sonnel was involved in the original system development. 

19. System Benefits 

This section of a system description identifies and describes 
the primary advantages offered by the ADPS. The section is divided into 
two paragraphs. The first paragraph discusses the proposed benefits on 
which the system was originally justified. The second paragraph dis¬ 
cusses the benefits actually realized by system implementation. Broad 
categories of benefits that may be mentioned include cost savings, time 
savings, and new capabilities not available prior to implementation of 
this ADPS. 

20. Cost Factors 


This section of a system description displays eight develop¬ 
mental and operational cost factors in individual horizontal bar graphs 
showing the known proposed and actual values of each cost factor. The 
cost factors represent the subject ADPS and not the whole ADP instal¬ 
lation. Hours/month of hardware use cost factors are all prorated to 
a standard month of 7 30 hours. The eight cost factors are defined as 
follows: 


a. Man-Months of Development Effort 

This is a developmental cost factor representing the 
number of man-months expended by manager, analysts, programmers, 
and operators to develop the ADPS during the development phase begin¬ 
ning with system design and ending when the system is declared opera¬ 
tional. During this development phase, activities such as detailed sys¬ 
tem design, programming, checkout, and equipment installation are 
accomplished as required. 

b. Months of Elapsed Development Time 

This is a developmental factor representing the number 
of calendar months elapsed from the date system design for the ADPS 
is begun to the date the system is declared operational. 

c. Dollars of Hardware Cost for Program Checkout 

This is a developmental cost factor representing the 
hardware cost for computer hours used for program checkout during 
the development phase of the ADPS. 

d. Hours/Month of Hardware Use for Application Production 

This is an operational cost factor representing the 
monthly computer hours on the base computer(s), charged to the user 
of the ADPS for processing, that are classified as application production. 
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e. Hours/Month of Hardware Use for Program Maintenance 

This is an operational cost factor representing the 
monthly computer hours used for application program maintenance of 
the operational ADPS on the base computer(s). 

f. Number of Operations Personnel 

This is an operational cost factor representing the num¬ 
ber of personnel including operators, scheduling personnel, data edit 
personnel, magnetic tape librarians, report binders, managers, etc. , 
allocated to the ADPS during the operations phase. Operations person¬ 
nel all perform their functions within, and within the immediate vicinity 
of, the computer room. 

g. Number of Program Maintenance Personnel 

This is an operational cost factor representing the 
number of personnel including managers, analysts, and programmers 
allocated to perform the process of improving, changing, and correct¬ 
ing programs of the ADPS during the operations phase. 

h. Dollars/Month of Hardware Cost 


This is an operational cost factor representing the 
cost of monthly computer hours used for application production and pro¬ 
gram maintenance on the base computer(s) and peripheral computer(s). 

Each horizontal bar graph is followed by commentary to clarify 
the proposed and actual values of the cost factor and to explain any dif¬ 
ferences between these values. 

21. Future Plans 


This section of a system description briefly describes any 
currently planned or contemplated changes or additions that may affect 


the ADPS. 
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II. COST ESTIMATION 
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aetabUahed la atap ]. 
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Weal (atep 2) aa4 Wtaootal (atep 4) Uaea between adjacent 
lee-line a. 


4. On the t enter ie«-|raph. determine the value that Maa-Moneha ef 
Development Effort le expected to he, hy logarithmically Inter po¬ 
uting the imteraectlea point of the vertical (atep 2) end horuantal 
(atep 4) tinea between edjeceet lee-Uaea. 

7. On the bottom ieotraph. determlae the value that Mae-Mo a the af 
Development Effort le expected to he greeter than 70 percent ef 
the time, by logarithmically interpolating tha iatareectioa point 
ef the vertical (atep 2) end horieontel (atep 4) line* between adja¬ 
cent tee-liaee. 




FIGURE 5 - COST ESTIMATING ISO-GRAPH FOR MAN-MONTHS OF DEVELOPMENT EFFORT 
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FIGURE 6 - COST ESTIMATING ISO-GRAPHS FOR NUMBER OF PROGRAM MAINTENANCE 
PERSONNEL 
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FIGURE 7 - COST ESTIMATING ISO-GRAPH FOR NUMBER OF OPERATIONS PERSONNEL 













































































































































































































































































































































































































































































































FIGURE 8 - COST ESTIMATING ISO-GRAPH FOR DOLLARS PER MONTH OF HARDWARE 
COST FOR APPLICATION PRODUCTION 






































































































































































































































































































































































.FIGURE 9 - COST ESTIMATING ISO-GRAPH FOR DOLLARS PER MONTH OF HARDWARE 
COST FOR PROGRAM MAINTENANCE 
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III. SYSTEM DESCRIPTIONS 
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SYSTEM : Project ADOBE Data Reduction--ADOBE (IBM 7040/1401) 


DATA SYSTEM DESIGNATOR: B104 


DATA COLLECTION DATE; May 1966 


Contact for Additional Information 

Air Force Rocket Propulsion Laboratory 
Edwards Air Force Base 

Edwards, California 

Development 

Air Force Rocket Propulsion Laboratory 
Edwards Air Force Base 

Edwards, California 

Maintenance 

Air Force Rocket Propulsion Laboratory 
Edwards Air Force Base 

Edwards, California 

Pilot Installation 

None 

First Operational Installation 

Air Force Rocket Propulsion Laboratory 
Edwards Air Force Base 

Edwards, California 

Number of Operational Installations 

1 


FUNCTION : The users of ADOBE are the Propellant, Liquid Rocket, and Solid Rocket Divisions 
of the Rocket Propulsion Laboratory. One of the most important missions of these divisions is to 
test and verify operation of rocket motors by static firing. The exhausts of some of these rocket 
motors contain hazardous beryllium pollutants. ADOBE functions as a research and development 
support system to predict the distribution and level of these downwind pollutant concentrations in 
order to schedule and control rocket firings. ADOBE reduces data recorded in r.eal time at a 
rocket test site into reports that aid the users in evaluating test results. The data reduction is 
performed in a non-real-time mode. 


ORGANIZATION: 



(User) (D*v*lop*r/Op«r»tor) 
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HISTORY : In 1963 the Air Force Rocket Propulsion Laboratory (AFRPL) and Air Force 
Cambridge Research Laboratories directed Project Sandstorm, a series of 43 field tests to study 
the diffusion of exhaust clouds from small solid rocket motors containing beryllium. Tests were 
conducted with grains weighing from 8 to 65 pounds, with their exhausts diffusing over a two- 
square-mile instrumented course. The data reduction programs originated as a part of Project 
Sandstorm--the first effort in the beryllium diffusion area for AFRPL. The basic design for the 
204* tower wind speed and direction programs was embodied in an IBM 650 program previously 
developed at AFRCL. It was planned to convert the code directly to the IBM 1401, but this did 
not prove feasible and the programs were completely rewritten for the IBM 7040. Also in 1963, 
the original data reduction program for exposure was written. 

The test results from Project Sandstorm could not be extrapolated to larger motor sizes of 
current interest with any degree of confidence. In 1964 Project Adobe began, using 500- to 4000- 
pound grains that diffuse their exhausts over a 28-square-mile instrumented course. Both pre¬ 
vious computer programs were extensively revised, and data reduction programs for temperature 
differential, 12-foot wind, and cloud tracking were added to the capability. This programming 
was completed in 1965, with the exception of cloud tracking, which is still continuing. 

Communication between the user and the programmer analyst was informal. The user would 
complete a work order requesting a particular programming effort, and the user and program¬ 
mer supervisor discussed the job. The user then informally discussed the details with the pro¬ 
grammer assigned to the task. For the remainder of the development effort, the user, program¬ 
mer supervisor, and programmer communicated verbally approximately on a weekly basis. 

After the program was operational, the original programmer did any needed program mainte¬ 
nance. The programmer functioned as an analyst, programmer, and maintenance programmer. 

A small amount of AFRPL's computer inputs, outputs, and library tapes were classified as 
confidential, but security measures have not significantly hindered ADPS installation or operation 


SCHEDULE: 
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ADOBE Sheet 3 of 7 


DESCRIPTION; The ADOBE system reduces instrumentation data obtained from a 204-foot me- 
terological tower, 12-foot wind sets, air and soil samplers, and phototheodolite cameras. The 
raw data are converted from analog strip charts to digital punched cards by an operator on a 
Benson Lehner Oscar J. , or from handwritten reports directly to punched cards. 
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WORKLOAD: 


PROCESSING 

JUNCTIONS 



HARDWARE: 



1 - , - —' 


Swttt liable Tape Units 

IBM 7040 IBM 1401 


Com - 
puter 

i- ir si 
J)eli V- 

ery 

Mb/Yr 

Wort) 

or 

Clin r. 
Mach. 

Add 
rime 
( sj 

Intel n il Storage 

Kxlcrn.il 

Peripheral Devices 

Card Reader 

/Punch 

Printer 

Cycle 

Time 

W o rd / 
Char. 
S»7.e 
(bits) 

Word/ 
Char. 
Ca- 
pac tty 

Stora 


No. 

Read 
Speed 
(cards / 
min) 

Punch 
Speed 
(cards / 
min) 

No. 

Speed 

No. 

M-»K 

Tapes 

_ 

Trans. 

Rate 

IBM 

7 04 0 

4/M 

Word 

10 

K 

36 

4,090 

S- 729 II 
1-77.9 IV 

1 5K to 
62. SK 

None 

... 

— 

None 


JUKI 

1401 

9/60 

Cha r. 

2 JO 

1 l.*» 

6 

4K 

4- 

729 V 

60K 

1 - 

1402 

800 

2S0 

1 - 

1403 

600 


Comment : The <-<piipment lias been highly reliable: approximately 98% uptime. 
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SOFTWARE : Software for the IBM 7040 consisted of an IBSYS monitor executive system, a 
FORTRAN IV compiler, and a MAP assembler. All software was delivered by IBM with the 
machine in September 1963. 

COMMENT: There is currently one person assigned full time to system programming at RPL. 
His time^is mainly spent updating the software according to frequent manufacturer modifications. 
The software has caused no problems in the development or operations of the ADOBE system. 


A PPLICATION PROGRAM DEVELOPMENT : Two of the five ADOBE data reduction programs 
were extensively revised from Project Sandstorm effort as discussed in the history section. 

The other programs were designed and coded in FORTRAN IV by contractor personnel from 
Telecomputing Services, Inc. , who received details by written work order and verbal communi¬ 
cation. Documentation was informal and not at a system level, because of the extreme inde¬ 
pendence of the programs, but in the form of program listings held by the cognizant program¬ 
mer. The existing IBM 7040/1401 computer system was used for testing with no new hardware 
or software capabilities required. Turnaround time was normally 4 to 8 hours. The program 
independence negated the need for an integrated system test. Development is currently going on 
and records were not kept of the number of hours of testing that have been utilized. Daily time 
cards, with time allocated to the appropriate work order, and monthly time reports were sub¬ 
mitted during development. Program status reports were kept by Telecomputing Services, Inc. 
personnel only. 


FILE CONVERSION: No file conversion was involved in ADOBE development. 
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DOCUMENTATION: No formal documentation exists. 


PERSONNEL: 




Number of People 

Number of Years 

Activity 

Function 

Sampled 

Allot fttcl to 
System 

In ADP 

In Scientific 
Computation 

Of College 


Manager 

5 

0.1 

10.5 

3.5 

3.0 

Development 

Analyst 

None: Programmer a Function na Programmer 

/Analysts 


Programmer 

5 

7.0 

3.5 

2.0 

3.0 

Operations 

Manager 

5 

0.1 

10.5 

3.5 

3.0 

Operator 

1 

1 .0 

5.0 

3.5 

X 


OPERATIONS : The computer operation at RPL is staffed 24 hours a day Monday through Friday 
and 8 hours on Saturday. It operates as a closed shop. ADOBE is one of many applications on the 
IBM 7040/1401 system. Generally, an 8-hour backlog exists. There is no schedule other than 
for IBM maintenance. Processing is on a normal and hot priority basis, with "first come first 
served" scheduling. 

Comment : The idle time is large for this type of installation! possibly due to the scheduling 
concept. 


Off 

210 hr. m 


Schri Mt 
20 hrs »> 


Unschd Mt 
1 hr, If 

Idle 
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Prep (all other eppe) 
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*r«-p (AIM)PF 
epp) I hr 1% 

I to v V Mt 
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I ‘rod (all ■ >th«' r 
epp* I I S2 hre 211% 
‘Prep (ell <>th«*r 
appe) 7 hre |% 
\Prog Dev * Mt 
(.ill olhor eppe) 
127 hre I 7% 
h K (AHOHK 

epp) I hr 1% 

< hg I . H, («|| 

other eppe) 

> hr*, r 


APPLICATION PROGRAM MAINTENANCE : The application program maintenance effort is 
essentially a continuation of the application program development effort. The development 
programmer /analysts are also the maintenance programmers, andthe same informal methods 
of communication between them and the user are used. Most of the effort is improvement 
rather than error correction. 

COMMENT: The program maintenance effort is driven by the continually changing data re¬ 
duction requirements. The requirements change because new meteorological instrumentation 
is installed in the field and because the user desires different outputs. 
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BENEFITS : Proposed : ADOBE was preceded by Project Sandstorm, which existed to study the 
exhaust clouds From small, solid rocket motors with grain weights between 8 and 65 pounds and 
instrumentation over a 2-square-mile instrumented course. Benefits ADOBE was to offer above 
Project Sandstorm include the ability to handle rocket motors of 500- to 4,000-pound grains, 
instrumentation over a 28-square-mile course, and additional instrumentation. ADOBE was to 
provide an improved data processing capability, which included programs for processing temper¬ 
ature differentials, outputs from 12-foot wind towers, and cloud trackings. 

Actual: The increased quantity and variety of instrumentation required was procured, enabling 
the test of 500- to 4,000-pound grains. Testing was expanded to include detonation/burn tests and 
contamination tests as well as diffusion of rocket motor exhausts. The required data processing 
capability was realized with the exception of cloud tracking, the development of which is continu¬ 
ing at present. 


COST FACTORS: 


Man-Months of Development Effort (D«v.) 

Proposed: 15 1 1 

Actual: 21 ■■■■■■■ 

Comment : ADOBE ia in continuing development due to system refine¬ 
ments and requirement changes. The project's development is estimated 
to be 90 percent complete at the current 21 man-months. 

Months of Elapsed Development Time (Dev.) 

Proposed: Unk CZ 

Actual: 25 ■■■■■ 

Comment : Forty-five test firings were scheduled to be completed b«- 
tween July 1964 and July 1965, by a test directive which was prepared in 
place of a DAP. At present, 39 test firings have been completed. The 
schedule slippage was due to weather conditions. 

Dollars of Hardware Coat for Program Checkout (Dev.) 
Proposed: Unk CZ 

Actual: Unk W 

Comment : Records of computer hours for program checkout were not 
kept. Records of computer hours by application were net produced 
before 1966 except by DSAP code, which is too general to Isolate 
ADOBE programs. 


Hours/Month of Hardware Use for Application Production (Op.) 

Proposed: Unk CZ 

Actual: 12 ■■■■■HBIMHi 

Comment: The actual number reflects usage on the IBM 7040 during 
April i4^6. Ten hours were used for ADOBE application production 
on the peripheral IBM 1401. 


Hours/Month of Hardware Use for Program Maintenance (Op.) 
Proposed: Unk CZ 

Actual: 9 

Comment : The actual number reflects usage on the IBM 7040 during 
XprlT 1966. Eight hours were used for ADOBE program maintenance 
on the IBM 1401. 

Number of Operations Personnel (Op.) 

Proposed: 1 » 1 

Actual: l.l 

Comment : In addition to one operator, one manager spends 10 percent of 
his time on ADOBE. 

Number of Program Maintenance Personnel {Op.) 

Proposed: 1 I *1 

Actual: 1.2 

Comment : The actual number of personnel Is prorated from 7 program¬ 
mers on the basis of time spent on ADOBE program maintenance. There 
Is also one system programmer assigned full time to"software maintenance 
for all applications at RPL. 

Dollars/Month of Hardware Cost (Op.) 

Proposed: Unk CIZ 

Actual: 4,363 

Comment : The actual dollar value Is based on 16 hours of application 
production and 9 hours of program maintenance. 


FUTURE PLANS: A DAP is being processed for an on-line micrometeorological recording and 
display system (MICROMET). MICROMET will provide input for further processing by ADOBE. 
Since MICROMET will perform data calibration, formatting and editing, the processing time for 
ADOBE will be reduced. In the MICROMET system, meteorological instrumentation output will 
be fed through A/D converters to an on-line computer. The on-line computer will reduce the in¬ 
coming data and drive output equipment including a display map of wind vectors and temperature 
readings. The number of manual steps in preparing data for ADOBE will thus be reduced, im¬ 
proving accuracy and timeliness. 
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SYSTEM : Accrued Military Pay System--AMPS (NCR390) 


DATA SYSTEM DESIGNATOR: H003A 


DATA COLLECTION DATE: May 1966 


Contact for Additional Information 

Directorate of Data Automation 

Air Force Accounting and Finance C, nter 
3800 York Street 

Denver, Colorado 

Development 

Air Force Accounting and Finance Center 
Denver, Colorado 

Maintenance 

Air Force Accounting and Finance Center 
Denver, Colorado 

Pilot Installation 

Ent Air Force Base 

Colorado 

First Operational Installation 

Ent Air Force Base 

Colorado 

Number of Operational Installations 

125 


FUNCTION : The users of the system are Air Force bases throughout the world, the Air Force 
Director of Personnel Planning, and the Director of the Budget. A common mission of the users 
is military pay distribution and accounting control. AMPS functions as a management support 
system to prepare paychecks for military personnel and to provide accrual accounting of the 
military pay funds. The reports of accountability are consolidated at the Air Force Accounting 
and Finance Center (AFAFC) and forwarded to the Air Force Director of Personnel Planning and 
the Director of the Budget. 


ORGANIZATION: 



(V..r/Op.r.tor) --- Admli\i.lr.tlv. JU.pon.lbiitty 
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HISTORY ; The 1949 pay system, using a hand-posted military pay record for each Air Force 
member, recorded the pay dollars actually disbursed to a member. It did not record or report 
amounts "earned by" and "properly payable to" each member monthly. Yet the total amount 
earned, or accrued, represented the true total dollar liability against the Air Force appropria¬ 
tion. This liability, considerably greater than the total dollars actually spent in cash or checks, 
is a critical budget factor needed and wanted by the Director of Personnel Planning and the Di¬ 
rector of Budget in the Pentagon. 

From the many pay studies and tests undertaken by Air Force specialists came two con¬ 
cepts for a new pay system. The first called for centralized control of all Air Force pay ac¬ 
counts using a high-speed communication system linked to a large-scale computer at the Air 
Force Accounting and Finance Center (AFAFC). The other concept approached the problem on 
a decentralized basis, using desk-size computers at paying bases. Both systems prescribed 
mechanized record-posting and provided for accumulating and reporting pay management data 
on an accrual basis. 

In October 1962, Department of Defense Directive 7040.3 directed all military services to 
implement an accrual accounting system for military pay within 2 years. Since the central¬ 
ized computer system could not be operational within this tight time frame, the Comptroller of 
the Air Force directed that the decentralized system be implemented and operational by July 
1964. The system would be known as the Air Force Accrued Military Pay System (AMPS). 

Planning sessions were held in January and February 1962 with representatives of Head¬ 
quarters USAF, AFAFC, and the major air commands. The group's recommendations resulted 
in Headquarters USAF being responsible for policy guidance, systems and program approvals, 
and AFAFC for systems, procedures, and program development and implementation, and the 
major air commands for full program support and execution at command and base levels. 

The use of the NCR 390 computer was specified to the Air Force Accounting and Finance 
Center by Headquarters, USAF, Accounting and Finance and had been used at Ent AFB, 

Colorado, in a single base prototype system. Operators of the system were sent to a special 
Air Training Command School on AMPS at Sheppard AFB prior to the actual use of the system 
on an Air Force base. The system is operational on 174 computers located at 125 Air Force 
bases. 

The AMP system design was a cooperative effort of the Directorates of Military Pay and 
Data Automation at the Air Force Accounting and Finance Center. The Directorate of Military 
Pay developed requirements for program development and changes while ensuring the integrity 
of the Military Pay System. The Directorate of Data Automation was responsible for system 
analysis and programming. 


SCHEDULE; 
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DESCRIPTION: The primary function of AMPS is to prepare paychecks for military personnel. 
The pay computations are run twice a month. In addition to check issuance, AMPS has the ca¬ 
pability for accepting temporary and permanent pay changes for military personnel and for pro¬ 
ducing quarterly accrual FICA (Federal Insurance Contributions Act) and FITW (Federal Income 
Tax Withheld) reports. A punched paper tape with ail accrued expenditures by categories is also 
prepared by each base. These tapes are sent by each base to AFAFC, which consolidates them 
on the RCA 501 to prepare an Air Force-wide RAOMP (Report of Accrued Obligations for Military 
Pay). The RAOMP report is forwarded to Hq. USAF Director of Personnel Planning and the Di¬ 
rector of the Budget. 


OPENING or MILITARY PAY RECORD (MPHI PROCESS RETIREMENTS. DISCHARGES. TRANSfERS IN. TRANSfERS out 
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HARDWARE: 


NCR 390-3 
Console and Cen¬ 
tral Processing 
Unit 


NCR 361-1 
Paper Tape 
Reader 


NCR 381-2 
Card Reader 
(Modified 
IBM 026) 


NCR 362-1 
Strip Tape 
Reader 


NCR 462-1 
Paper Tape 
Recorder 


NCR 390 


Com¬ 

puter 

First 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(us) 

Internal Storage 

Peripheral Devices 

Cycle 

Time 

(us) 

Word 

Size 

(Nu¬ 

meric 

Char.) 

Word 

Ca¬ 

pacity 

Card 

Reader 

Paper Tape Reader 

Paper Tape Punch 

No. 

Read 

Speed 

(cards/ 

min) 

No. 

Read 
Speed 
(char. / 
sec) 

No. 

Punch 
Speed 
(char. / 
sec) 

NCR 

390 

S/61 

Nu¬ 

meric 

Char. 

11,300 

1,200 

12 

200 

1- 

381-2 

15 

1-361-1 

1-362-1 

400 

1-462-1 

17 


Comment: The carriage of the NCR 390 reads information from magnetic ledger cards, 
which contain up to 200 words in magnetic strips. 
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SOFTWARE : The NCR 390 does not have assemblers, compilers, or an executive system. 

Comment : Conventional software is not supplied with the NCR 390 because of the extremely 
small scale of the machine. 


APPLICATION PROGRAM DEVELOPMENT : The system design was a cooperative effort of the 
Directorates of Military Pay and Data Automation within AFAFC. The Directorate of Military 
Pay was responsible for analysis and determination of military pay requirements and AMPS 
system design. The Directorate of Data Automation was responsible for program design, coding, 
and program checkout. All programs were written in absolute machine language. The pro¬ 
grammers operated their own programs, and were able to make roughly two checkout runs per 
day. The computer operated two shifts a day, 6 days a week during program checkout. NCR 
allowed 330 days of free use for as many hours as desired. An estimate of 12 hours a day or 
3,744 hours of a possible 7,920 hours were used for checkout. The Directorate of Military Pay 
compiled an exhaustive set of test data for the system test, and subsequently verified the results 
of the system test with the Directorate of Data Automation. PERT charts, progress charts, and 
work measurement charts were maintained during development for management control. 


FILE CONVERSION: File conversion was performed on a decentralized basis by the AFO's re¬ 
sponsible for the payroll records. Conversion was made from manual payroll records to mag¬ 
netic ledger report forms. Information from manual payroll records was manually converted to 
Form 1926 Alphanumeric Header Data on punched cards and to Form 1927 Military Pay Record 
Opening Data on punched paper tape. These inputs were then submitted to the normal MPR 
opening subsystem to generate the master file of MPR's. At a typical base the conversion proc¬ 
ess was accomplished within a cwo-week period (between pay dates) using the entire AFO staff 
(between 15 and 40 people depending on base size) working on a two-shift basis plus overtime. 
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DOC UM ENT AT ION : The basic system description and user's manual is AF 177-105, which is very 
voluminous and exhaustive. Effort is presently being expended to make the material of this man¬ 
ual more understandable. The basic documentation of AMPS programs and program operation is 
AF 171-15; it contains program narratives, detailed data formats, flow charts, and program op¬ 
erating instructions. Whena change is made toa program affecting AF 171-15, a change sheet for 
insertion or replacement is provided to all bases along with a new program tape. Any changes to 
the programming system are originated by an "ADP Projects Request/Authorization" form, which 
is signed and approved by responsible parties in both the Directorate of Military Pay and Data 
Automation. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Year* 

Sampled 

Allocated to 
System 

In ADP 

In Military 
Pay 

Of College 

Development 

Manager 

V 

9.3 

12.5 

17.0 

4.5 

Analyst 

23 

23.0 

14.5 

21.5 

U nknown 

Programmer 

22 

22.0 

4.0 

1.5 

U nknown 

Operation* 

Manager 

l 

0.5 

2.0 

4.0 


Operator 

6 

3.0 

2.0 

2.0 

X 


OPERATIONS : The computer operation is staffed at Lowry AF3 8 hours a day, 5 days a week. 
It operates as a closed shop. AMPS is the only application on the NCR 390 computer. A 
monthly master schedule is prepared for each of the operational computers located throughout 
the world. 

Comment : All development and maintenance of AMPS is performed on one NCR 390 computer 
dedicated exclusively to program development and maintenance at AFAFC. 



APPLICATION PROGRAM MAINTENANCE: Problems arising at the installations are transmitted 
to the Directorate of Data Automation at AFAFC, where the problems are analyzed. The instal¬ 
lations are advised immediately of any temporary changes required until the Directorate can re¬ 
lease a new program tape and documentation. Along with the eight programmers involved in 
program maintenance at AFAFC, there are a branch chief and systems analyst who also spend 
full time on the system. Sixty percent of the people involved in program maintenance were in¬ 
volved in the original development of the system. The program maintenance activity is divided 
into three areas: (1) program corrections, 5 percent; (2) program improvements, 25 percent; 
and (3) changes due to legislative requirements such as FICA and FITW, 70 percent. The aver¬ 
age turnaround time for checkout work is 24 hours. 

Comment: None. 
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BENEFITS ; 

Proposed : Benefits which AMPS was designed to provide that the existing manual system did not 
provide include: (1) reporting of military pay accounting information on an accrual basis to the 
Director of Personnel Planning and the Director of the Budget; (2) more timely reporting of 
military pay accounting, FICA, and FITW data; and (3) a net cost saving of approximately $1.7 
million annually. This was justified on an estimated saving of approximately 1,200 military pay 
personnel. The personnel saving would be $6.0 million while added machine rental and mainte¬ 
nance would be $4.3 million, resulting in a net saving of $1,7 million annually. 

Actual: (1) reporting of military pay accounting information on an accrual basis to the Director 
of Personnel Planning and the Director of the Budget was accomplished; (2) more timely report¬ 
ing of military pay accounting, FICA and FITW data was accomplished after some initial prob¬ 
lems with the AMPS computer system and operations personnel; and (3) revised manpower re¬ 
quirements permitted the elimination of only approximately 240 personnel, corresponding to 
about $1.2 million annually. Since additional equipment costs were $4.3 million, this resulted 
in a net annual additional cost of $3.1 million over the existing manual system. 


COST FACTORS: 


Man-Month* of Davalopmant Effort (Dev.) 

Propo • Unk Q 

Actual: 704 mmmmammm 

Commant : No formal DAP wu prepared for AMPS. A DOD diractlva 
ot Octobar 1962 dlractad that all branchaa of tha aarvica aatabliah ac¬ 
crual pay ayatama by Octobar 1964. Thia diractlva did not atata an 
aatlmata for man-montha of davalopmant affort. 

Month* of Elapaad Davalopmant Tima (Dav.) 

Propoaad: Hi -'-- "^3 

Actual: 18 ■■■■■■■ 

Commant: July 1. 1964 waa tha oparatlonal data aatabliahad by Hq. 

U5AF. 

Dollar* of Hardware Coat for Program Chackout (Dav.) 
Propoaad: Unk CE 

Actual: 37.178 

Commant : Tha numbar of hour* of actual chackout waa 3.744 hour*. Thia 
waa computed by multiplying a productive chackout aatlmata of 12 houra/ 
day by 344 day*, tha actual numbar of day* uaad for program chackout. 
NCR allowed 330 day* of unlimited daily free uaa for chackout. 

Houra/Month of Hardwara Uaa for Application Production (Op.) 

Propoaad: Unk CL 

Actual: 277 rnmmmmmmmi 

Comment : Tha actual numbar reflect* uaaga on the NCR 390 during 
March 1966 at Lowry AFB. 


Hour a/Month of Hardware Uaa for Program Maintenance (Op.) 
Propoaad: 01 

Actual. 01 

Commant : All AMPS program maintenance la dona only at AFATC. where 
it ia~a*tlmated that 176 houra/month arc uaad for that purpoee. The NCR 
390 at AFAFC la uaad only for AMPS program maintenance. 

Numbar of Operation* Paraonnal (Op.) 

Propoaad: 3.41 » 

Actual: 3.3 WMaMH 

Commant : The actual numbar rapraaanta three full-time operator* and on* 
analyat~3*voting 30 percent of hi* time to AMPS at Lowry AFB. Thar* ar* 
two full-tima AMPS operator* at AFAFC. 

Numbar of Program Maintenance Paraonnal (Op.) 

Propoaad: 01 

Actual: 01 

Comment : Tha actual numbar rapraaanta maintenance programmers at any 
operational alt*. Eight maintenance programmer* at AFAFC perform all 
AMPS maintenance. A branch chief and on* analyat alao a pa ad full time on 
AMPS. 


Dollara/Month of Hardwara Coat (Op.) 


Propoaad: 1,724 f— i 

Actual: 1.723 

Commant : Thia amount la tha baalc rental charge par month for a alngl* 
KICR 390 at any oparatlonal aita and the NCR 390 uaad axclualvaly for pro¬ 
gram maintenance at AFArC. 


FUTURE PLANS : AMPS is a decentralized interim system which was quickly implemented to 
meet a DOD directive. Future plans call for the installation of a Centralized system to replace 
AMPS. System study of the centralized system is presently being conducted. 
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SYSTEM : Data Services Workload Control System--DSWC (IBM 7080/1401) 


DATA SYSTEM DESIGNATOR; P044 


DATA COLLECTION DATE: July 1966 


LOCATION: 


Contact for Additional Information 

SACS San Antonio Air Materiel Area 

Kelly Air Force Base 

San Antonio, Texas 

Comptroller (Data Management Division) 
Hq. , Air Force Logistics Command 
Wright-Patter son Air Force Base 

Dayton, Ohio 

Development 

San Antonio Air Materiel Area 

Kelly Air Force Base 

Texas 

Ogden Air Materiel Area 

Hill Air Force Base 

Utah 

Comptroller (Data Management Division) 
Hq., Air Force Logistics Command 

Wright-Patter a on Air Force Base 

Ohio 

Maintenance 

San Antonio Air Materiel Area 

Kelly Air Force Base 

Texas 

Pilot In eta llation 

Hone 

Fir at Operational Installation 

San Antonio Air Materiel Area 

Kelly Air Force Base 

Texas 

Number of Operational Installation* 

8 


FUNCTION : The users of DSWC are the Data Center and Data Services of the AFLC Air 
Material Areas, and the Data Center and Data Management Division of Headquarters AFLC. 
The mission of the users is the efficient processing of data and the generation of desired 
information products. DSWC functions as a management support system to provide a standard 
system for use by the AFLC Data Centers for the identification and control of data services 
operations and products and the scheduling of data services resources. It also provides the 
Data Management Division of Headquarters AFLC with management reports containing the 
actual and forcasted use of automatic data processing equipment and personnel. 


ORGANIZATION: 



(Developer/Ussr) 


AM A Data Cantar 


(Oparator/Uaar) 
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HISTORY : Prior to 1963 several efforts to develop automated methods for manpower control 
and workload scheduling were underway at Headquarters Air Force Logistics Command (AFLC) 
and at some of the AFLC Air Materiel Areas (AMA's), The manager of the Data Management 
Division of Headquarters AFLC became aware of the duplicated efforts and formed a task force 
with the responsibility to develop a means of consolidating these efforts into a single automated 
system. The task force derived a data system specification in a report titled The Automatic 
Data Processing Resources Management System (ARMS ). The AMA*s received this report in 
August 1963 and tSeir criticism and comments were requested. After receiving their replies, 
the system was redesigned and the specifications in the form of a DAP were submitted to 
AFADA. Based on verbal approval by AFADA, the Data Management Division of AFLC beg n 
work on the project in January 1964. The San Antonio Air Materiel Area (SAAMA) was desig¬ 
nated as the development site with support supplied by Ogden Air Materiel Area (OOAMA). The 
proposed initial operational date of July 1964 proved unreasonable and was changed to October 
1964. The systern went operational simultaneously at all AMA's in January 1965. 

A system monitor from the Data Management Division, Headquarters AFLC, supervised 
the entire development at SAAMA. Analysts were located at SAAMA and two programming 
groups were formed, one at SAAMA and one at OOAMA. The group at OOAMA was in daily 
telephone contact with the analysts at SAAMA throughout the system development. 

DSWC is operational at the following eight sites: Rome AMA, Sacramento AMA, San 
Bernardino AMA, San Antonio AMA, Oklahoma City AMA, Ogden AMA, Warner Robbins AMA, 
and Hq. AFLC. 


SCHEDULE: 
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DESCRIPTION: The Data Services Workload Control system identifies, plans, controls, and 
schedules all AFLC data services operations. The AFLC data processing installations are pro¬ 
vided with uniform procedures for manpower and EDPE scheduling and other benefits such as 
mechanically prepared operator instructions (run sheets), external tape labels, and partially pre¬ 
punched utilization cards. Headquarters, AFLC, receives data showing actual and forecast use 
of system analyst/programmer personnel by data system at each installation as well as showing 
EDPE use by data system, projected by 12 months (AF-E6, part 8B). Inputs consist of man¬ 
power and EDP utilization in the form of either cards or reports punched on cards. The outputs 
consist of a series of reports on data system equipment and requirements, labor (programmer/ 
analyst) availability, monthly and daily work schedules and status reports, and a master di¬ 
rectory of mechanized operations. 



To tlq. , USA I 


Out pul to ADI* 
Manager. Monthly 


ADP Operation. 


To Cogni.anl 
Programmer, and 
ADP Manag.ra 


ADP Programming 

Manager. 
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DATA BASE 

Char, in Data Baae: 

17,270,000 

Percent of Char, on D/A Storage: 

NA 

Mllllaeconda of Acceaa Time for D/A: 

NA 

No. of Data Baae Record Typea: 

3 

No. of Data Baae Recorda: 

203,500 

Percent Growth Rate/Mo.: 

0.2 

Char. /Mo. of Update Input: 

1,836,000 


WORKLOAD: 


PROCESSING 

FUNCTIONS 


Char. /Mo. of Input 

1 

Volume: 

1,836,000 

No. of Input Trana* 


action Typea: 

38 

No. of Input 


Data Field a: 

237 

Percent of Input 


Rejecta: 

Unk 


♦ 


K.y 


% # .5 

}u CJ 


t 

« 

i 


lOOf. 
90 
80 
70 
60 
50 
40 
30 
20 
10 
0 % 


LJt 


ft 


t 

u 


A 


Total Source Instruction*: 
Total Object Inatructiona: 
Hra./Mo. of Application 
Production: 


Baae Computer(a) 

208,100 
208,100 


Peripheral 
Compute r( a) 

Unk 

Unk 

67 


Char. /Mo. of Out* 


put Volume: 

13,070,000 

No. of Output 


Formate: 

33 

Reeponee Time 


(second*): 

NA 


HARDWARE: 



IBM 1406 

IBM 1401 

Core 

Central 

Storage 

Proceeeing 

Unit 

Unit 


IBM 1403 
Printer 


IBM 1402 
Card 

Read/Punch 


2-IBM 7080'e 



2-lBN 
729-IV 
Tape 
Unite . 


4-IBM 1401'e 



•IBM 1401 


Com¬ 

puter 

Firet 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(as) 

Internal Storage 

External 

Storage 

Peripheral Devicee 

Card Reader /Punch 

Printer 

No. 

Read 

Speed 

(carde/ 

min) 

Punch 
Speed 
(carde/ 
min) 

No. 

Speed 

(1pm) 

Cycle 
Time 
(u •) 

Cha r. 
Sire 
(bite) 

Char. 

Ca¬ 

pacity 

No. 

Mag. 

Tapee 

T rane. 
Rate 

2-IBM 

7080 

9/61 

Char. 

11 

2 

6 

160,000 

20 - 
729 VI 

to 

90K 

None 

— 

— 

None 


4 -IBM 
1401 

9/60 

Char. 

230 

11.5 

6 

8,192 

2 - 

729 IV 

22.5K- 
62.5K 

1402 

800 

250 

1 - 

1403 

600 

IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

8.192 

4- 

7 29 II 

1 5K- 
41.6K 

1402 

800 

250 

1 - 

1403 

600 


Comment : The equipment configuration varies with the installation, both between AMA'e 
and Hq AFLC. The configuration depicted above is for the San Antonio AMA, 
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SOFTWARE : Software for both the IBM 7080 and IBM 1401 consisted of an Autocoder 
assembler and general input and output utility routines. The IBM 7080 also had a sort 
program available. 

Comment : The software is maintained by IBM. The DSWC system used the available 
software extensively. 


APPLICATION PROGRAM DEVELOPMENT : Policy and system design criteria were developed 
under the direction of the Data Management Division, Hq. AFLC. SAAMA personnel, 
augmented by personnel from OOAMA, were responsible for the development and initial im¬ 
plementation. The programmers coded the programs in Autocoder II from flow charts and 
specification documents. Each program, 17 for the IBM 1401 and 9 for the IBM 7080, was 
checked out independently at both SAAMA and OOAMA using the partially built files which 
were being built at each site on already existing hardware common to all AMA's and AFLC. 

The system checkout, which lasted two weeks and used live data, was performed at SAAMA 
with some assistance from OOAMA personnel. The computer checkout hours were mostly 
on the IBM 1401 with 1,350 hours logged and the IBM 7080 with 230 hours logged. Each program 
was well documented, as was the entire system design during development by 2 or 3 persons 
involved full time with documentation. The entire development was supervised by a system 
monitor from the Data Management Division, Hq. AFLC. 


FILE CONVERSION: An extensive period of file conversion went on simultaneously with the 
development of the* system. The three files, A, B, and C, had to be built to help with check¬ 
out. Checkout at both Ogden and San Antonio was performed with these partially built files. 

Two individuals were required full time to build these files at each AMA. One was the system 
monitor, who, together with a clerk assistant, worked closely with the individual programmers 
of each AMA. All programmer/analysts in AFLC were required to participate part time in 
the collation of program data for the files. It took about five months to complete these files 
at the AMA*8. 
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DOCUMENTATION: Each program was initially documented with a file of input and output formats and 
a description of the system design. During the development phaBe 2 or 3 persons worked full time with 
documentation. The major documents of this syBtemare (1) Data Services Workload (P044), AFLCM 
300-38, 26 Aug. 1964 (a users* manual and system description with format specifications); (2) main¬ 
tenance documents (a file containing program listing, transmittal letters with attachments, etc.); and 
(3) related documents on administrative regulation, such as AFLCR 300-10, which are used to create 
or modify files of P044. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
System 

In ADP 

In Area 

Of College 

Development 

Manager 

1 

1 

20 

20 

Unknown 

Analyst/Programmer 

16 

16 

11 

11 

Unknown 

Operations 

Manager 

4 

0.1 

Unknown 

Unknown 

Unknown 

Operator 

89 

2 

2 

Unknown 

XT 


OPERATIONS : The computer operation is staffed at SAAMA 24 hours a day, 7 days a week. It 
operates as a closed shop. DSWC is one of many applications on the IBM 7080's and 1401 's. 
DSWC is the master scheduler for both the daily and the monthly schedules. The daily schedule 
for each computer is displayed on closed circuit TV. Five IBM 1401 computers are used to 
process DSWC. The pie chart below reflects utilization as if one IBM 1401 did all of the DSWC 
application processing, and not all five computers, which is actually the case. 

Comment: The SAAMA installation does all the program development and maintenance for all the 


operational sites of DSWC. 




Production 
(DSWC «pp) 

2 hr. 1% 

Prog Dev and 
Mt (DSWC app) 

2 hr. 1% 

Prod (all other 
app.) 4 31 hr. 57% 


Prog Dev and 
Mt (.11 other 
app.) 69 hr. 9% 


OH 

157 hr. 21% 



Prod (DSWC app) 

12 hr. H 

Prog Dev A Mt (DSWC app) 
7 hr. I $ 

Prod (all other app.) 

35S hr. 49)1 


Prog Dev A Mt (all other app.) 
9* hr. 13# 


Prod (DSWC 
app) 67 hr. 9% 
Prog Dev A Mt 
(DSWC app) 

14 hr. 2% 

Prod (all other 
app.) 284 hr. 39% 


Chg Lo.t (.11 
other app.) 1 hr t% 


Prog Dev A Mt 
(all other app.) 
70 hr. 10% 


IBM 1401 (A) 


APPLICATION PROGRAM MAINTENANCE: The program maintenance is currently performed 
at SAAMA by programmer/analysts who were all involved in the original development of 
DSWC. Problems arising at any of the AMA's are isolated and pertinent information is trans¬ 
mitted to SAAMA. Resultant corrections from SAAMA are inserted at each AMA by resident 
analysts or programmers. 

Comment: None. 
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BENEFITS : Proposed : DSWC was designed to provide ADP management with responsive tools 
to make timely and accurate decisions on ADP resources (including ADP personnel and ADPE) 
utilization. DSWC was to make uniform methods of computing, scheduling, and reporting avail¬ 
able throughout the AFLC. Computer operations also were to be simplified and streamlined by 
providing operator sheets, tape labels, and partially prepunched computer utilization cards. 

Actual: DSWC is operational on an IBM 7080/1401 system at each Air Materiel Area (AMA) of 
the AFLC. Scheduled operations are put on a large board, which is then displayed by closed 
circuit TV to the operator. DSWC also provides Hq. AFLC with forecasts of ADPE and ADP 
personnel use, and subsequently compares actual usage with the forecast. 


COST FACTORS: 


Man-Months of Development Effort (Dev.) 

Proposed; UnkCZ 
Actual; 

Comment : A task force, formed at Hq. AFLC In early 1963, prepared 
a report called the ADP Resources Management System (ARMS). The 
system specifications from this report were used to prepare a DAP In 
August 1963, which was approved verbally by AFADA In January 1964 
and officially In May 1964. No estimate of man-months was contained 
in the DAP. 


Months of Elapsed Development Time (Dev.) 

Proposed: 6 1 1 

Actual: MHHHHi 

Comment : The DAP stated that command-wide implementation would be 
completed by I September 1964. The programming phase of development 
took longer than planned, causing schedule slippage. 

Dollars of Hardware Cost for Program Checkout (Dev.) 
Proposed; UnkQ 

Actual: 140,660HHHHH 

Comment : Program checkout required 230 hours on the IBM 7080 com- 
puter and 1,350 hours on the IBM 1401 computer. 

Hours/Month of Hardware Use for Application Production (Op.) 

Proposed: 10 1 ) 

Actual; 

Comment : Sixty-seven hours were used for DSWC application production 
on the peripheral IBM 1401's. The actual number reflects usage during 
March 1966 on the IBM 7060. The DAP stated an estimate of 30 hours/ 
month per AMA for the IBM 1401 computers. 


Hours/Month of Hardware Use for Program Maintenance (Op.) 
Proposed: Unk Q 

Actual: 9 

Comment : The actual number reflects usage during March 1966 on the IBM 
Program maintenance for DSWC Is done only at SAAMA. The opera¬ 
tional AMA's and Hq. AFLC have monitor programmer/analysts who collect 
program error data to send to SAAMA and Install corrections from SAAMA. 
Fourteen hours were used for DSWC program maintenance on the peripheral 
IBM 1401's at SAAMA. 


Number of Operations Personnel (Op.) 

Proposed: Unk f~7 

Actual; 2 BI^BH^BHiHB 

Comment : The actual number of personnel Is prorated from 89 operators 
at SAAMA on the basis of machine time used for DSWC. 

Number of Program Maintenance Personnel (Op.) 

Proposed: Unk CZ 

Actual: 5 

Comment : The actual number of personnel represents full-time DSWC 
maintenance programmer/analysts at SAAMA. There are programmer/ 
analysts at each AMA and at Hq. AFLC who Isolate problems and transmit 
program errpr data to SAAMA for correction, as well as Install program 
corrections from SAAMA. 

Dollars/Month of Hardware Cost (Op.) 

Proposed: 1.208 0 

Actual: 10.960 BBBHH^BM 

Comment : The actual dollar amount includes the cost of program main¬ 
tenance done only at SAAMA. This program maintenance cost Is approx¬ 
imately $4,289 per month at SAAMA. 


FUTURE PLANS : 

time. 


There are no indications of changes or additions to this system at this 
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SYSTEM : Base Level Inventory Control System--GE/BSS (GE 225) 


DATA SYSTEM DESIGNATOR: D002 


DATA COLLECTION DATE: April 1966 


LOCATION: 


Contact for Additional Information 

Directorate of Data Automation 

Military Airlift Command 

Scott Air Force Base 

Belleville, Illinois 

Development 

Scott Air Force Base 

Illinois 

Maintenance 

Scott Air Force Base 

Illinois 

Pilot Installation 

None 

First Operational Installation 

Scott Air Force Base 

Illinois 

Number of Operational Installations 

7 


FUNCTION : The prime users of GE/BSS are the base supply offices at the various Military 
Airlift Command bases. The only other user is the Accounting and Finance Office, which 
processes the financial aspects of the inventory system. The mission of the prime user is 
controlling the distribution, ordering, and inventory level of aircraft replacement parts for 
the Military Airlift Command. GE/BSS functions as a management support system in 
processing real-time supply transactions and generating management reports. 


ORGANIZATION: 



(Operator) 


<U..r) 
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HISTORY: GE/BSS evolved from an attempt in the late 1950*8 to simultaneously introduce 
automation techniques to a variety of the Military Airlift Command (MAC) functions using an 
IBM 7070 computer at Charleston AFB. The attempt was too ambitious for the system tech¬ 
nology of the period and resulted in degrading the inventory function as the requirements for 
real-time operation could not be met. 

Headquarters USAF decided to transfer the functions one at a time to another computer 
and employ the modular concept of design. Of the 33 functions in the Charleston system, base 
supply was given the highest priority for the new system and is the only function presently oper¬ 
ating in the new computer. 

The project began at Scott AFB in April 1962 with the programming a joint Air Force 
and General Electric effort. The amount of coding required was underestimated and therefore 
the available manpower was insufficient to meet the schedule. An additional time-lag factor 
in development was the inclusion of new requirements and design factors for MLLSTRIP. The 
system became operational at Scott AFB in December 1962 and during the next 18 months six 
more similar systems were developed for installation at other bases in the Military Airlift 
Command. 

System analysts from the Base Supply Office provided technical guidance to the General 
Electric programmers. The number of contractor programmers was inadequate and Air Force 
and Civil Service programmers were added to the effort. Small groups under close supervision 
of Air Force programmers were formed and assigned specific tasks for the remainder of the 
development. 

UE/BSS is operational at the following seven AFB*s: Lajes AFB, Travis AFB, Scott AFB, 
Hunter AFB, McGuire AFB, Charleston AFB, and Dover AFB. 


SCHEDULE: 
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DESCRIPTION: There are two main system functions: (1) posting, i.e. , the processing of 

real-time supply transactions, and (2) report generation. Posting input is by punched cards 
representing supply transactions; for example, a request for an aircraft part by maintenance 
or the recording of new stock purchases. Each transaction updates the supply record on the 
disk and records the transaction on the history tape, A requisition form is output when s part 
has been requested. The history tape is used to produce management reports. 


Prom Supply Pereonnel „ 


Supply Tr.n.ic 
lion, l,,u, 
Requeet 
Receipt,, etc. 



POSTING FUNCTION 




Requisitioning 
end Receipt, 


Shipping 

Procedure, 


Stock 

Control 


— 


1 




Property 

Accounting 

•» 

executive 

Routine 

•» 

Special 
Logistical 
Precederea 




l 




Proc«4yrt« 


Turn in 
Procedure, 


Baa, Funded 
Item 

Management 








b 


To Supply Personnel 



To Supply Pereonnel 


Received From Supply. 

Office, 


Special Input 
Card, lo 
Control 
Reporting 


3H 


REPORTING FUNCTION 










Summariae 


Select 


Fermat 



Data 


Data 


Data 








Merge 


Sort 


Output 



Data 


Data 


Data 








Daily: 

Pooling Traneaitioi 
Re,taler. Reject 
l.tei In,, etc. 


Semi-Annual: 

Pret,sue Inventory 
l.latln,. 

Unit Price Review 
lill 


Quarterly: 

Item Record dating. 
Detail Due In/Out 
dating, etc. 



Monthly: 

Baee Supply Report, 
Potting Tran,action 
Register, etc. 


A, Required: 

Due Out on Deactivated 
Organlaatlon, Routing/ 
Relmb. dating 
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HARDWARE: 


P225B 

Printer 




GE 225 


Com¬ 

puter 

First 

Dellv- 

ery- 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

<»') 

Internal Storage 

External Storage 

Peripheral Device! 

Card Reader/Punch 

l 

Printer 

Mag Tapes 

Disk 

No. 

Mag 

Tapes 

Trans. 

Rate 

No. 

Disks 

Trans. 

Rate 

Char. 

Ca¬ 

pacity 

Ac¬ 

cess 

Time 

(ms) 

No. 

Read 

Speed 

(cards/ 

min) 

No. 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

(1pm) 

Cycle 

Time 

(a*) 

Word 

Sire 

(bits) 

Word 

Ca¬ 

pacity 

GE 

225 

1/61 

Word 

36 

18 

20 

4,096 

3 

15K to 
60K 

1 

62.5 

28M 

180 

1 

400 

1 

100 

1 

900 



Comment: At Travis AFB there are two hardware configurations to handle an unusually 
heavy workload and at Scott AFB an extra core memory module was added 
to facilitate development programming. 
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SOFTWARE : Software for the GE 225 consisted of a GAP assembler, program diagnostics, 
and utility routines. The software was delivered by GE with the equipment in early 1962. 

Comment : The software performed well and has required little modification or correction. 
One exception was the routine which randomly accessed the disk file and which required con¬ 
siderable reprogramming. It was felt by the developers that the software contributed signifi¬ 
cantly to system development. 


APPLICATION PROGRAM DEVELOPMENT : The GE/BSS proposal called for all program¬ 
ming to be done exclusively by GE programmers with technical direction from Air Force 
system analysts. The development approach adopted was to begin work on the most critical 
aspects of the system first, solve them, and then work on the next most important areas of 
the system. This resulted in some unnecessary redesign work. The technical effort suffered 
due to some design shortcomings, resulting from an overly optimistic technical estimation by 
GE and the Air Force system analysts and an apparently arbitrary and short USAF schedule. 
Air Force and Civil Service programmers were added when it became apparent that the 
number of GE programmers was inadequate. The programs were all written in GE assembly 
language, GAP. Each function was divided into subprogram segments of approximately 1,000 
words each because of limited core space. The posting programs were written almost entirely 
without benefit of GE software. The programmers operated the computer themselves during 
the six months checkout period, getting 4 to 5 short test runs on the 24-hours-per-day con¬ 
tinually operating computer. The criteria for the system test were specified by the supply 
analysts. During development a thorough documentation file was maintained of each program*s 
interaction with its environment. Proposed design features, changes to programs, additional 
requirements, and detected conflicts were documented in an internal document series known 
as Program Information Letters (PIL). This was an effective programming control during 
the development period and has been praised by the technical staff involved. Daily progress 
reports from the programmers were collected and analyzed. 

Comment : Another cause for schedule slippage was the inclusion of additional requirements, 

such as MILSTRIP, which required redesign and additional coding. A frozen set of specifica¬ 
tions would have significantly aided the development phase. 


FILE CONVERSION: The data base to be employed in the GE 225 system was essentially the same 
as that used on the IBM 7070 system at Charleston AFB except for differences in format. The 
conversion was done by special programs written for the IBM 7070 which dumped the file onto 
magnetic tape and punched cards in a format acceptable as input to the GE 225. Approximately 
200,000 records of about 100 characters each were converted. Three weeks were required 
to complete the down-loading of the IBM 7070 and up-loading of the GE 225. The system 
data were audited before and after the loadings to verify the conversion. 
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DOCUMENT A I ION: At the completion of development (December 1962), the system documen¬ 
tation was produced: System Requirements (AF 67-1), Program Description (MM 67-4) and 
User's Manual (MM 171-14). 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
System 

In ADP 

In Supply 

Of College 

Development 

Manager 

16 

6 

9.0 

8.0 

3.5 

Analyst 

6 

8 

5.0 

12.0 

Unknown 

Programmer 

7 

24 

4.0 

3.5 

Unknown 

Operations 

Manager 

1 

1 

4.0 

1.0 

Unknown 

Operator 

3 

7 

5.0 

3.0 



OPERATIONS : The computer operation is staffed at Scott AFB as required by workload. It op- 
erates as a closed shop. GE/BSS is the only application on the GE 225 computer. A monthly 
schedule is utilized by the operational sites with the allowance of priority runs at any time. 
Comment : All development and maintenance of GE/BSS is performed at Scott AFB. The average 
production time is 312 hours/month for the operational sites, excluding Scott AFB, with a maxi¬ 
mum of 488 hours/month. Machine maintenance time is large (15 percent). 



APPLICATION PROGRAM MAINTENANCE: All program modifications and improvements are 
done at Scott aFb. Other site programmers are used exclusively to gather data pertaining to 
program errors and to install program changes. The operational programs have required 
little maintenance or modification. 

Comment: The small requirement for program maintenance probably arises from the fact 
that the system has been operational for a relatively long period of time. 
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BENEFITS : Proposed: GE/BSS was proposed to provide increased management control, re¬ 
duction of supply manpower, and more timely fulfillment of maintenance requests in the 
Military Airlift Command. The concept of an automated supply system had been demonstrated 
through a pilot automation effort on the IBM 7070 at Charleston AFB. 

Actual: GE/BSS provided increased management control and more timely fulfillment of main¬ 
tenance requests. 


COST FACTORS: 


Man-Months of Development Effort (Dev.) 

Proposed: 55 O 

Actual: 375 ■■■■■■ 

Comment : It wii felt by the developers that the schedule imposed on the 
programming group by Hq. USAF was highly optimistic and apparently 
arbitrarily short. This unrealistic schedule led to a poorly designed 
system that required some unnecessary redesign work. Air Force and 
civil service programmers were added to the development effort when it 
became apparent that the number of GE programmers was Inadequate. 

Months of Elapsed Development Time (Dev.) 

Proposed: 5 I- 1 

Actual: 1} 

Comment : GE/BSS was decreed operational on 1 July 1962 by Hq. USAF 
directive. Equipment selection was made In February 1962. Program 
checkout was begun in April 1962. Insufficient manpower and Inclusion 
of new requirements, such as MILSTRJP, during the development delayed 
system operation to December 1962. 


Dollars of Hardware Cost for Program Checkout (Dev.) 
Proposed: Unk CZ 


Actual: 212,000 ■■■■■ 

Comment : The checkout computer was in constant 24-hour use for 
6 months of the period April to December 1962. It was felt by the de¬ 
velopers that the supplied software contributed significantly to system 
development. An approximate total of 4,512 hours was used for pro¬ 
gram checkout. 


Houra/Month of Hardware Use for Application Production (Op.) 

Proposed: Unk CZ 


Actual: 176 

Comment : The actual number reflects usage on the GE 225 during June 1965 
at &cott AFB. The six operational GE/BSS Installations, excluding Scott 
AFB, averaged 316 hours. Maximum usage was 488 hours at Travis AFB. 


FUTURE PLANS : This system is currently being phased out. All base supply functions 
are being transferred to the AF standard base supply system on the UNIVAC 1050-11. 


Houra/Month of Hardware Use for Program Maintenance (Qp.) 
Proposed: Unk CZ 

Actual: 75 ■■■■■■■■■■ 

Comment : The actual number reflects usage on the GE 225 during June 
1965 at Scott AFB. AUGE/BSS program maintenance la done at Scott AFB, 
Field program maintenance activity at the other operational sites is con¬ 
cerned only with the collection of program error data to send to Scott AFB 
and the Installation of corrections from Scott AFB. 

Number of Operations Personnel (Op.) 

Proposed: 5 i "H 

Actual: 8 

Comment : The actual number of operators at Scott AFB Is 6. The other 
6 ope rational sites average 8 operators, with a maximum of 12 at 
Travis AFB. 

Number of Program Maintenance Personnel (Op.) 

Proposed: 3 [ 1 

4 ■HHHHHi 

Comment : There are programmers at the operational sites, other than at 
Scott AFB shown here, but they are used exclusively to collect program 
error data to send to Scott AFB and Install corrections. There are two 
programmers at each operational site except Travis and McGuire AFB'e, 
which have three programmers each. 

Dollars/Month of Hardware Coat (Op.) 

Proposed: 9,400 i , 

Actual: 9.400 ■■■■■ 

Comment : This amount is the basic rental charge per month for all 
operational sites except Travis AFB. 
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SYSTEM : Global Weather Central--GWC (IBM 7094 Mod I) 


DATA SYSTEM DESIGNATOR: L001 


DATA COLLECTION DATE: April 1966 


Contact for Additional Information 

3rd Weather Wing 

Offut Air Force Base 

Omaha, Nebraska 

Development 

SAC Headquarters 

Offut Air Force Base 

Nebraska 

Maintenance 

SAC Headquarters 

Offut Air Force Base 

Nebraska 

Pilot Installation 

None 

First Operational Installation 

SAC Headquarters 

Offut Air Force Base 

Nebraska 

Number of Operational Installations 

1 


FUNCTION : The user of GWC is the 3rd Weather Wing--Air Weather Service of the Military 
Airlift Command. The mission of the user is to support the Strategic Air Command and 
classified military activities with scheduled and tailored weather products. GWC functions 
as an operational and intelligence system to produce weather products such as analyses, 
prognoses, and forecasts for dissemination to supported units throughout the continental 
United States and overseas. Teletype information containing observations of weather con¬ 
ditions at the earth's surface and at various altitudes is input to GWC and the data are analyzed 
and correlated with previous weather conditions to prepare the weather products. 


ORGANIZATION: 



(Operator) (Dovalopor) (Dovaiopor) (Dovoiopor) 
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HISTORY: The GWC was developed in response to ever-increasing weather requirements being 
levied on the manual weather prediction and analysis capability of the 3rd Weather Wing. The 
initial system design was based on certain programs operating on the SAC IBM 704 and on a 
system developed by the Joint Numeric Weather Prediction Unit (JNWPU) at Suitland, Maryland. 
Initially, paper tape from teletype was used as the primary input source of observation data. 

The basic system was subsequently modified substantially by changing forecasting and analysis 
models, adding new products, upgrading the IBM 7090 to an IBM 7094 Mod I, installing an ADX 
ITT 7300 communication computer, and adding another IBM 7094 Mod I computer. 

The development personnel for the GWC system were weather specialists with a very high 
average educational level, cross-trained to utilize computer skills. This approach was 
adopted because of difficulty in obtaining data processing personnel and because of the com¬ 
plexity of the weather application. The basic plan for system implementation was to replace 
manually generated weather products with the automatically generated products only after the 
automatic system had been fully verified. This approach enabled the system to be developed 
in a time-phased manner. 

The development activity was performed primarily by the Directorate of Scientific Services 
and the Automation Division. The Directorate of Scientific Services was responsible for the 
formulation of the basic models used in the system. In many cases, personnel of the Di¬ 
rectorate wrote programs to verify the concepts and models which they had developed. The 
actual production programs were written by personnel in the Automation Division. No clear 
distinction between programmer and system analyst was made, since virtually all people 
doing programming had a meteorology background. 

GWC is housed in two separate facilities approximately one mile apart. One of these 
facilities is in a hardened underground area resulting in materially increased costs for this 
facility. Due to the distance between the two sites, an IBM 7711 data transmission unit is 
necessary which would not have been required for a single facility. The estimated facility 
preparations costs for the non-hardened installation were $100,000. 

A large portion of the GWC output is unclassified. During the development and production 
of highly classified outputs the environment is so secure that many programmers involved in 
checkout of less highly classified projects are denied access to the computer room, resulting 
in less efficient checkout than could have been accomplished otherwise. 


SCHEDULE: 
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DESCRIPTION: GWC input containing observations of weather conditions at the earth*s surface 
and at various altitudes in the upper air is received via teletype. All input except for relevant 
observations is stripped off prior to further analysis. About 50 percent of the data monitored 
over the teletype wires is not useful to GWC. The observations are then analyzed and correlated 
with previous weather conditions and forecasts are prepared. Analysis and forecast runs are 
made four times daily. The runs at 0600 and 1800 hours are not transmitted to the field but are 
analyzed in-house and used in the production runs at 0000 and 1200 hours. 


20 TTY Lines 
With Worldwide 
Weather Observ- 
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WORKLOAD: 


DATA BASE 

Char. In Data Baaa: 

3.790,000 

Percent of Char, on D/A Storage: 

NA 

Millisecond* of Access Time for D/A: 

NA 

No. of Data Base Record Types: 

7 

No. of Data Base Records: 

Unk 

Percent Growth Rate /Mo.: 

Unk 

Char. /Mo. of Update Input: 

Unk 


PROCESSING 

FUNCTIONS 


Char. /Mo. of Input 


Volume t 

715.400,000 

No. of Input Trans- 


action Types: 


No. of Input 


Data Fields: 

418 

Percent of Input 


Rejects: 

4.5 


Kay 


la .$ r t f I \i ] 

is cl 3 3, 5 S && 5 


100 % 
90 
• 0 

70 

60 

50 

40 

30 

20 

10 

0% 


g 

$1 

Ax 


A 


00 00 00 00 


rijL 

tin 


OUTPUTS 


Al 


Total Source Instruction* 
Total Object Inetructlona: 
Hri./Mo. of Application 
Production; 


Base Computar(a) 

99.790 
124.200 


Paripharal 
Computer! a) 

Unk 

Unk 


Cher./Mo. of Out¬ 


put Volume: 

S98.000.uuu 

No. of Output 


Formats: 

121 

Response Tim* 


(seconds): 

NA 




Com- 
pit - r 

First 

Dellv- 

sry 

Mo/Yr 

Word 

or 

Chsr. 

Msch. 

Add 

Tims 

(u*) 

Interne) Storage 

External 

Storage 

Peripheral Devices 

Card Reader/Punch 

Printer 

PT Reeder 

PT Punch 

Cycle 

Tims 

(U*l 

Word/ 

Chsr. 

Six* 

(bits) 

Word/ 

Chsr. 

Ca¬ 

pacity 

No. 

Meg 

Tepes 

Trens. 

Kate 

No. 

Read 
Spe ed 
(cards/ 
min) 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

Upm) 

No. 

Reed 

Speed 

(char./ 

see) 

No. 

Punch 

Spesd 

(char./ 

••c) 

IBM 

7094 

9/62 

Word 

4 

2 

36 

32K 

2*729IV 

if "7 mi 

22.5K- 

ISK- 
41.6K 

1 • 
711 

2S0 

too 

1- 

716 

ISO 

None 

... 

None 

... 

IBM 

7094 

9/62 

Word 

4 

2 

36 

32K 

12*72911 

1SK- 
41.6K 

l- 

711 

2S0 

100 

1- 

716 

ISO 

None 

... 

None 

... 

IBM 

1401 

9/60 

Cher. 

230 

11 . s 

6 

8K 

1*729 U 

ISK- 
41.6K 

1 - 

1402 

800 

2S0 

1- 

1403-2 

600 

1- 

1903 

soo 

1- 

1902 

ISO 

IBM 

1401 

9/60 

Cher. 

230 

11 . s 

6 

BK 

2-729U 

ISK* 
41.6K 

I - 

1402 

800 

2S0 

1 - 

403*2 

600 

None 

... 

None 

... 

ITT 

7300 

unk 

Word 

10 

S 

18 

32K 

2-7320 

ISK 

None 



None 

— 

Con¬ 

sole 

400 

Con¬ 

sole 

20 


Comment: Other peripheral devices include a Benson Lehner Data 
Plotter and a CV 1357 Converter. 
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SOFTWARE : The entire IBM-supplied software packages for the IBM 7094 are available to GWC 
as is the SHARE library. GWC has been using the FORTRAN monitor system with the 
FORTRAN II compiler, FAP assembler, and a standard IBM-supplied library including some 
special GWC routines. GWC has also been using a GWC-developed control program AUTO and 
the IBM IBSYS executive system in conjunction with FORTRAN IV. The IBSYS executive in¬ 
cludes a MAP assembler, a COBOL compiler, Report Program Generator (RPG), and a linkage 
editor. 

Comment: The FORTRAN monitor system and the IBSYS executive system are used for program 
development but not for production runs. All production is run under AUTO, the GWC- 
developed control program, which requires considerably less core than either the FORTRAN 
monitor system or IBSYS. Little of the IBSYS executive’s capability is being used. Virtually 
none of the SHARE library routines are being used at this time, although some were used during 
the early development stages. 

Maintenance of the IBM-supplied software requires two people on a full-time basis, one 
supplied by IBM and the other by GWC. GWC is very happy with the support received from 
IBM (on-site and from IBM headquarters) and feels that this support tremendously enhances 
the maintenance of the support software. 


APPLICATION PROGRAM DEVELOPMENT : The GWC development activity was performed 
by the Directorate of Scientific Services and the Automation Division of the 3rd Weather Wing. 
The Directorate of Scientific Services was responsible for formulation and verification of the 
models and computational techniques used in GWC, while the Automation Division was respon¬ 
sible for programming the production programs, integrating these programs into the GWC 
system and verification of system operation. A clear distinction between analyst and pro¬ 
grammer was not made in the GWC system, since virtually all the people doing programming 
had a strong meteorology background. Development effort from other numeric weather proj¬ 
ects such as the Joint Numeric Weather Production Unit was used whenever possible. The 
programs were coded in FORTRAN II and FAP assembly language* The GWC system is com¬ 
prised of 86 separate programs, grouped together as 8 packages. Each package is run as a sub¬ 
system generating specific output products. The program testing was done using the FORTRAN 
monitor system. The development of the system was on a time-phased basis such that per¬ 
sonnel freed from the manual preparation of products could be utilized in further system de¬ 
velopment, The time phasing also allowed thorough verification of new products prior to op¬ 
erational use. Quarterly progress reports were submitted during development. 


FILE CONVERSION: No file conversion was involved in GWC development. 


71 
















GWC Sheet 6 of 7 


DOCUMENTATION : 3WWM 105-12 describes the centrally prepared products that are transmitted to 
field units. It provides information on the use of the products and verification information on selected 
forecast products. Documentation of the inter system workings and individual programs is generally 
inadequate. No formalized documents giving system flow charts, program flow charts, or narrative 
program descriptions were found. Documentation of program operational procedures is complete 
and is kept on cards for easy maintenance. 

personnel! " 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
System 

In ADP 

In Weather 

Of College 

Development 

Manager 

6 

6 

5.0 

13.5 

6.5 

Analyst 

25 

25 

2.5 

13.0 

7.0 

Programmer 

28 

28 

2.5 

9.5 

Unknown 

Operations 

Manager 

18 

18 

2.0 

11.0 

3.0 

Operator 

73 

73 

1.5 

7.0 



OPERATIONS : The computer operation is staffed 24 hours a day, 7 days a week. It operates as 
a closed shop. The GWC application shares both IBM 7094/1401 computer systems. The two 
IBM 7094/1401 installations are located at different sites, approximately 1 mile apart, neces¬ 
sitating transmission between sites of information via the IBM 7711. The IBM 7094/1401 (A) 
system is owned, while the (B) system is rented. 

Comment : An excellent daily master schedule is strictly followed to utilize the owned computers 
as much as possible and to obtain the most updated input before transmitting weather products at 
fixed intervals. Idle time on the leased computer is nonchargeable by the manufacturer. 

SchS Ml 



Prop (GWC 
•pp) K> hr. 4% 




Pr.p (GWC 
•pp) I hr 1% 

Pro, Dr* * Ml 
(GWC .pp) 14 hr. 
Pr»4 (.11 olh. r 
•pp.) 44 hr* 1 % 



Prod ICiWC 
•pp) I TO hr. iPfc 
Pro, l>»v 4 Ml 
(GWC app) )h hr. 1 % 
Prod (all oth.r 
•pp.) <4 hr. 4% 



APPLICATION PROGRAM MAINTENANCE : Current programming activity involves 59 per¬ 
sonnel and is divided into 4 areas: (1) new product programming, 19 percent; (2) program im¬ 
provements, 60 percent; (3) program corrections, 14 percent; and (4) program and/or product 
deletions, 7 percent. Program improvements include optimization of running time, tape manip¬ 
ulation changes for more efficient production flow, and improved data processing schemes. The 
Program Applications Branch is responsible for pre-production testing of all programs prior to 
their release to production. 

Comment: Program development as well as maintenance is a continuing and significant aspect 
of GWC. Due to the diversity and lack of control of weather observation input formats, program 
maintenance is constantly required to comply with changes in this area. Increasing require¬ 
ments in the field of weather analysis and forecasting have caused improvements in old weather 
models and concepts and the development of new ones. Thus, development programming activ¬ 
ity is always in progress with approximately the same number of people involved in develop¬ 
ment now as were involved during the original system development. 
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^ENEFITS s Proposed : The GWC was proposed to provide weather information, such as fore¬ 
cast, analyses, and special reports to the Strategic Air Command and other AF users. Prior 
to development of the GWC, these products were manually produced. The manual processing 
of weather data was rapidly becoming unfeasible by I960. New weather products including fore¬ 
casts at high altitudes were required. In addition, requirements existed for increased frequency 
of weather reports. 

Actual: The GWC has evolved over a number of years and is currently providing automated 
weather products twice daily. A number of new weather products and items or equipment have 
been added since the initial operational capability. Weather products requirements are con¬ 
tinually increasing, requiring plans to be developed for new programs and equipment. 


COST FACTORS: 


M»n-Month« of Development Effort (Dev.) 

Proposed: Unk CZ 

Actual: 4.404 

Comment : No formal proposal such as a DAP was prepared for the 
CWC. Tl»e GWC ADPS developed from ever-increasing weather re¬ 
quirements, and hence, proposal activities are to be found throughout 
the GWC development and operation. A substantial portion of the de¬ 
velopment effort to date, as represented here, may be regarded as 
program maintenance in the continual development of the GWC, 

Months of Elapsed Development Time (Dev.) 

Proposed: Unk t~7 

Actual: 21 ■■■■■ 

Comment : The Initial development effort of the GWC was considered to 
Have begun in January I960 and ended in October 1961, as represented 
here, when it became operational. New programs, however, are con¬ 
tinually being developed to meet the ever-increasing needs of AF 
weather- users. 


Dollars of Hardware Cost for Program Checkout (Dev.) 
Proposed: Unk Q 

Actual: Unk W 

Comment: No records were kept for computer hours used for GWC 
program checkout. 

Hours /Month of Hardware Use for Application Production (Op.) 

Proposed: Unk CZ 

Actual: 500 

Comment The actual number reflects usage during March 1966 on both 
UTKTTff^T I computers. A total of 1,040 hours was used for GWC appli¬ 
cation production on the two IBM 1401 computers and the ITT 7300 ADX. 


Hours/Month of Hardware Use for Program Maintenance (Op.) 
Proposed: Unk CZ 

Actual: 140 ■§■■■■■■■■ 

Comment : The actual number reflects usage during March 1966 on both 
IBM 7094 I computers. A total of 37 hours was used for GWC program 
maintenance on the two IBM 1401 computers and the ITT 7300 ADX. 

Number of Operations Personnel (Op.) 

Proposed: 44 1 1 

Actual: 91 ■■■■■■■■■ 

Comment : The proposed number, consisting of 12 operators and 32 data 
preparation personnel, came from an anticipated manpower projection 
established in January I960. The actual number of personnel consists of 
73 operators and 16 managers. 

Number of Program Maintenance Personnel (Op.) 
Proposed: 41 1 I 

Actual: 59 

Comment : The proposed number, consisting of 1 manager, 26 analysts, 
and 12 programmers, came from an anticipated manpower projection 
established in January I960. The ac ual number consists of 6 managers, 
25 analysis, and 26 programmers. 

Dollars/Month of Hardware Cost (Op.) 

Proposed: Unk CZ 

Actual: 240,297 
Comment: None. 


FUTURE PLANS: Experience at the GWC has been one of continually adding programs and 
equipment to meet ever-increasing needs of AF weather users. GWC personnel currently 
estimate that by FY 1968 the equivalent of five IBM 7094 Mod I computers will be required. 
To meet these increasing requirements, a DAP is presently being prepared outlining the 
anticipated future requirements. The proposed system is to include such state-of-the-art 
features as multiprogramming, multiprocessing, large-scale direct access memory, and 
on-line consoles. 

Because of the huge investment in programming (99 percent of the programs are in 
IBM 7094 machine language) it is felt that the new computer system must have the capability 
of emulating the IBM 7094. Other functional refinements desired include the use of a finer 
mesh grid to improve model accuracy and the use of satellite and aerospace data. 
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SYSTEM : Merged Accountability and Fund Reporting III--MAFR (RCA 501/301) 


DATA SYSTEM DESIGNATOR : H053 and H055 
DATA COLLECTION DATE: May 1966 


Contact for Additional Information 

Directorate of Data Automation 

Air Force Accounting and Finance Center 
3800 York Street 

Denver, Colorado 

Development 

Air Force Accounting and Finance Center 
Denver, Colorado 

Maintenance 

Air Force Accounting and Finance Center 
Denver, Colorado 

Pilot Installation 

None 

First Operational Installation 

Air Force Accounting and Finance Center 
Denver, Colorado 

Number of Operational Installations 

1 


FUNCTION : The immediate user of MAFR ILL is the Directorate of Central Accounting of the 
Air Force Accounting and Finance Center. Ultimate and prime users of MAFR III are the 
U.S. Treasury Department and the Air Force Director of the Budget. The mission of the 
prime users is to monitor Air Force expenditures and maintain an accountability of all Air 
Force Funds. The Treasury Department, of course, has other missions beyond Air Force 
accountability. MAFR III functions as a management support system to maintain accountability 
of cash expenditures and status of funds allocated for specific materials or services and 
consolidates the data in monthly reports. 


ORGANIZATION: 



(U.er) 
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HISTORY : Certain insufficiencies in the MAFR II System necessitated a major reengineering of 
the system in order to generate the products required by the user. The primary insufficiency 
was the lack of ability to produce reports on Status of Funds. The accounting categories for 
Status of Funds for MAFR III are not the same as those used in MAFR II, which necessitated a 
complete system redesign for MAFR III. The concept for MAFR HI was approved by Head¬ 
quarters, Air Force Accounting and Finance Center (AFAFC) with subsequent approval by 
Headquarters USAF. The project started in December 1962 and was operational in July 1963. 

A planned schedule of events during development was prepared and coincided with the actual 
development schedule. 

The reengineering of MAFR II to MAFR HI was a joint effort of the Directorate of 
Central Accounting and the Directorate of Data Automation at AFAFC. Specific tasks were 
assigned to each with continuous coordination of activities. 

In general, the Directorate of Central Accounting was responsible for developing the 
accounting system concept, input formats, edit and balance criteria, output formats, and 
providing system test data. 

The Directorate of Data Automation was responsible for developing the EDP system 
concept and specifications, programming and program documentation, and testing and 
debugging. 

A joint responsibility of the two directorates was the implementation plan, developing 
operational schedules, reviewing systems, test output, establishing "live" operations, and 
monitoring initial "live” production for conformance to desired output. 

Since MAFR III became initially operational, 63 new programs have been added to the 
original 95 to add refinements and to satisfy additional customer requirements. 

A variety of documents were produced during the development of the MAFR III 
system. MAFR HI is generally a thoroughly documented system, and strong management 
control resulted in the proper flow and distribution of the generated documentation. 


SCHEDULE: 
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DESCRIPTION: MAFR III is an AF central accounting system for maintaining accountability 
“of cash expenditures and status of funds allocated for specific materials or services. MAFR 
III enables AFAFC to act as a clearing house for vouchers paid by one Accounting and Finance 
Office (AFO) for another AFO. Each AFO forwards the vouchers paid for other AFO's to 
AFAFC along with vouchers for its own payments. AFAFC then forwards the "for others' 1 
vouchers to the AFO for whom they were paid. In the process of receiving and distributing 
these reports, MAFR III maintains a complete Air Force-wide accountability which is con¬ 
solidated on a monthly basis into the Status of Funds Report and Cash Expenditure Report, 
which are sent to Hq. , USAF, and the Treasury Department, respectively. 
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WORKLOAD: 


DATA. BASE 


Char. In Data Base: 

28.550.000 

Percent of Char, on D/A Storage: 

NA 

Milliseconds of Access Tim* for D/A: 

NA 

No. of Data Base Record Types: 

11 

No. of Data Base Records: 

285.000 

Percent Growth Rate /Mo.: 

Unk 

Char. /Mo. of Update Input: 

18.880.000 


PROCESSING 

FUNCTIONS 


Char. /Mo. of Input 


Volume: 

18.880.000 

No. of Input Trans* 


action Types: 

85 

No. of Input 


Data Fields: 

81 

Percent of Input 


Rejects: 

±1 


f 


K.y 


it ft f S . 1 
IS cl 3 II S 53 8 


100 % 

90 

80 

70 

80 

SO 

40 

30 

20 

10 

0 % 


OUTPUTS 


ml 


JhL 


Total Source Instruction* 
Total Objact Instruction*: 
Hr*./Mo. of Application 
Production: 


Baso Compute r(a) 

25,000 

100.200 

148 


Perlphe ral 
Compute r(e) 

ISO 

719 


Char./Mo. of Out 
put Volume: 

No. of Output 
Formats: 158 

Response Time 
(seconds): NA 


401.800.000 


HARDWARE: 


RCA 501-1 




Console 




1 

Coneole 




1 





-!- 



RCA 561-3 

Hi-Speed 

Storage 

RCA 503 

Central 

Processing 

Unit 


RCA 547-6 

Tape 

Switch 

Control 

"I 

1 

1 

RCA 561-3 

Hi-Speed 

Storage 

RCA 503 

Central 

Processing 

Unit 


RCA 547-6 

Tape 

Switch 

Control 



RCA 501-2 


RCA 369-1 

Card Reader/ 
Punch Control 


RCA 330 

Card 

Reader/Punch 




RCA 316-1 


RCA 333 

On-Line Printer 


On-Line 

Control 


Printer 




RCA 316-2 


RCA 333 

On-Line 


On-Line 

Printer Control 


Printer 




RCA 393-1 


RCA 390 IBM 

581 


729 Tape 

Adapter 


Control 




RCA 311 Paper 


RCA 322 Paper 

Tape Reader 


Tape 

Control 


Reader 



RCA 301 


Com¬ 

puter 

First 

Dellv- 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(us) 

Internal Storage 

External 

Storage 

Peripheral Devices 

Card Reader/Punch 

Printer 

PT Read/Punch 

No. 

Read 

Speed 

(cards/ 

min) 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

(1pm) 

No. 

Speed 

(char./ 

sec) 

Speed 
(char. / 
sec) 

Cycle 

Time 

(us) 

Char. 

Sice 

(bits) 

Char. 

Ca¬ 

pacity 

No. 

Mag 

Tapes 

Trans. 

Rate 

RCA 

501 

11/59 

Char. 

360 

12 

6 

32,768 

11- 

581 

33K to 
66K 

None 

— 

... 

None 

... 

... 

... 

... 

RCA 

501 

11/59 

Char. 

360 

12 

6 

32,768 

8- 

581 

33K to 
66K 

None 

... 

... 

None 

... 

— 

... 

... 

RCA 

301 

2/61 

Char. 

67 

4.8 

6 

20,000 

729-11 

15K to 
41.6K 

I- 

330 

800 

250 

2- 

333 

1,000 

1- 
3 22 

1,000 

100 
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SOFTWARE : Software for the RCA 501's consisted of the following: (1) a COBOL compiler; 

(2) an EZCODE assembler; (3) a monitor and loader; (4) a sort and merge program package; 
and (5) a debugging package. 

Comment : Since the RCA computers had already been operational for a considerable period 
of time prior to MAFR III development, the software was well debugged. The only exception 
to this was a sort package. 


APPLICATION PROGRAM DEVELOPMENT: A systems concept document consisting of flow 
charts and listings oi necessary tasks ior the operation of the system was prepared by ana¬ 
lysts from the Directorates of Central Accounting and Data Automation within AFAFC. Sub¬ 
sequently, the Directorate of Central Accounting provided the accounting system concept, 
input formats, edit and balance criteria, output formats, and system test data. The Di¬ 
rectorate of Data Automation provided the EDP system concept and specifications, program¬ 
ming and program documentation, testing and debugging. The two directorates jointly pro¬ 
vided the implementation plan, operational schedules, a review of the systems test output, 
and the establishment, monitoring and verification of live operations and production. During 
checkout of the COBOL programs, the turnaround time was approximately 24 hours. The sys¬ 
tem was designed to operate on an existing RCA 501 installation. Pert charts, weekly progress 
reports, and work measurement reports were utilized during development. 


FILE CONVERSION: File conversion to MAFR III formats was an involved process since the 
file formats of MAFR III differed significantly from those of MAFR II. Special file conversion 
programs were written to extract information from a number of different MAFR II files and 
generate the appropriate MAFR III files. Approximately five man-months of effort and 30 
computer hours were required to generate the necessary MAFR III data base files prior to 
system operation. 
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DOCUMENTATION : Documentation was produced during development by both Central Accounting 
and Data Automation. Among the major documents are the following: Accounting Concepts, 

ADP System Concept, Customer Requirements, System Specification, Program Packages, 

Office Instructions, and AF Manuals (a user's manual). 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated 
to System 

In ADP 

In Accounting 

Of College 

Development 

Manager 

2 

2 

11 

20.5 

4 

Analyst 

4 

4 

4.S 

12.5 

Unknown 

Programmer 

19 

19 

6 

6 

U nknown 

Operations 

Manager 

I 

0.3 

Unknown 

U nknown 

U nknown 

Operator 

8 

8 

5.5 

Unknown 

XT 


OPERATIONS : The computer operation is staffed 24 hours a day, 6 and occasionally 7 days a 
week. It operates as a closed shop. MAFR is only one of several applications run on the two 
RCA 501's, the RCA 301, and the IBM 1401 computers. A monthly schedule, broken down into 
a daily and tentative next-day schedule, is utilized. 

Comment : The "Other Time" shown in the pie charts is made up of machine maintenance, idle 
time, machine error lost time, and off time. 


Off 

67 hra 9% "S. 

Schd Mt 

42 hra 6% \ 



Prod (MAFR 
app) 76 hra 11% 

Prog Dev-4 Mt 
(MAFR app) 

68 hra 9% 

Mach Error Loat > 

26 hra 4% \ 

Unachd Mt \ 

IS hra 2% 

Idle --- 

24 hra 3% 

Set Up /j 
36 hra 5% / 



Prod (all 
/ other appa) 

//■ 225 hra 31% 



Chg Loat (all / 



Prep (all other 

other appa) 25 hrs 3% / 

Chg Loat 



•pptj jc nn 9Ti 

- Prog Dev 4 Mt 

(MAFR app) 

7 hra 1% 

RCA 501 A 

(all other appa) 
87 hra 12% 


Mach Error Loat 
16 hra If 


Ch* 

Loat (all othar appa) 


Ch« Loat (MAFR app) 
6 hr a [f 



Prod (MAFR 
app) 70 hra 0% 

Prog Dev * Mt 
(MAFR app) 

54 hra 7% 


Prod (all other 
appa) 116 hra 31% 


Prap (all othar 
appa) I 3 hra 2% 

Prog Dev 4 Mt (all other appa) 
129 hra 18* 


Off 

49 hra 7% 
S. hd Mt 
31 hra 4% 
Mach Error Loat 
4 hra 1% 

Unachd Mt 
15 hra 2% 
Idle 

82 hra I 1% 

Set Up 
28 hra 4% 

Chg Loat (all 
other appa) 4 hra 1% 
Prog Dev * Mt 
(all other appa) 
71 hra 10% 



Prod (MAFR 
app) 84 hra 12% 

Prog Dev 6 Mt 
(MAFR app) 

30 hra 4% 


Prod (all other 
appa) 316 hra 42% 

Prep (all other 
appa) 16 hra 2% 


RCA 301 



Prod (MAFR 
app) 37 hra 5% 

_ Prog Dev * Mt 
(MAFR app) 
v 7 hra 1% 

Prod (all other 
appa) 306 hra 40% 


Prog Dev 6 Mt 
(all other appa) 
26 hra 4% 


APPLICATION PROGRAM MAINTENANCE : There are currently 10 programmers and one ana¬ 
lyst involved in program maintenance on MAFR III. Approximately 40 percent of these personnel 
were involved in the development of MAFR III. Any programming changes resulting in change 
pages to Customer Requirements, System Specifications, or Supplemental System Specifications 
must be approved by the Directorates of Central Accounting and Data Automation. 

Comment : Program maintenance is driven by the constant system improvement effort and con- 
tinual changes caused by varying customer requirements. There is very little program 
correction performed. 
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BENEFITS ; Proposed : MAFR III was to be a reengineering of the existing MAFR II system. 
MAFR III was to operate on the same equipment as MAFR II. The primary objective of MAFR III 
(as opposed to MAFR II) was to reduce the undistributed balances so that distributed balances 
could be used in current Status of Funds reports. 

Actual: MAFR II successfully reduced undistributed balances, from $250 to $300 million under 
MAFR II to approximately $40 million. This enabled more accurate and timely reports of 
Status of Funds to be produced. The development of MAFR III was based on the improvement 
of products being produced by MAFR II. 


COST FACTORS; 


Man-Month* of Development Effort (Dev.) Hour*/Month of Hardware Use lor Program Maintenance 


Proposed: Unk CZ 

Aitual: JO2 ■■■■■ 

Comment : No formal proposal was prepared for MAFR III. A system* 
concept was prepared for MAFR III by analysts from Data Automation 
and Central Accounting within AF AFC. This document consisted of 
flow charts and listings necessary lor the operation of MAFR III. 

Months of F .lapsed Development Time (Dev.) 

Proposed: 7 L 1 

Actual: “3 

Comment : The target operational date established in the system* concept 
document was 1 July I^*63. 

Dollars of Hardware Cost for Program Checkout 
Proposed: Unk □ 

Actual: 73,900 ■■■■■■■■■ 

Comment : Program checkout occurred from April to August 1963 on the 
RTTa“* 0T7 A total of Ub hours was used for program and system checkout. 

Hours/Month of Hardware Use for Application Production 
Proposed: Unk CZ 

Actual: 14b 

Comment : The actual number reflect* usage during March 1966 on the two 
RCA computer*. One hundred twenty-one hours were used for MAFR 
application production on tie prrtphrral RCA 301 and the IBM 1401. 


Proposed: Unk f~7 

Actual: 122 ■■■■■■■■ 

Comment : The actual number reflects ussge during March 1966 on the two 
RCA 501 computers. Thirty-seven hours were used for MAFR progrsm 
maintenance on the peripheral RCA 301 and the IDM 1401. 

Number of Operations Personnel 

Proposed: Unk Gf 

Actual: 8.3 BHBHHBH 

Comment : The actual number of personnel is prorated from 35 people 
base<j on machine hours for MAFR. 

Number of Program Maintenance Personnel 
Proposed: Unk CZ 

II 

Comment : The actual number of personnel represents 10 programmers 
and 1 analyst allocated to MAFR program maintenance. 

Dollsrs/Month of Hardware Cost 

Proposed: Unk C2 

Actual: 2*9 

Comment: None. 


FUTURE PLANS: A conversion to RCA 3301 computers is planned to relieve the overloaded 
RCA 501 computers. The programming impact of this conversion will be minimal since the 
vast majority of application programs are written in COBOL. Studies are being made to in¬ 
clude long-range AF and DOD objectives which could result in major changes in the MAFR III 
system; however, no specific plans have been approved at this time. 
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SYSTEM : Air Force MILSTAMP Central Data Collection--MILSTAMP (UNIVAC 1050/1107) 


DATA SYSTEM DESIGNATOR: O025E 


DATA COLLECTION DATE; April 1966 


Contact for Additional Information 

Data Services Division 

Sacramento Air Materiel Area 

McClellan Air Force Base 

Sacramento, California 

Development 

Sacramento Air Materiel Area 

McClellan Air Force Base 

California 

Maintenance 

Sacramento Air Materiel Area 

McClellan Air Force Base 

California 

Pilot Installation 

None 

First Operational Installation 

Sacramento Air Materiel Area 

McClellan Air Force Base 

California 

Number of Operational Installations 

1 


FUNCTION : The users of MILSTAMP are the Directorate of Transportation, Headquarters 
USAF; Directorate of Transportation, Headquarters AFLC; and the Directorates of Trans¬ 
portation of USAF Air Command. A common mission of the users is to evaluate military and 
civilian carrier performance by measuring and establishing standard transit and hold times. 
MILSTAMP functions as a management support system to prepare reports from "in transit" 
data pertaining to worldwide Air Force shipment and transshipment activities on a monthly 
basis for the users. 


ORGANIZATION: 



(D*v«lop«r/ Operator) 
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HISTORY : A Data Automation Proposal to develop the Air Force MILSTAMP Central Data 
Collection sybtem was forwarded by Headquarters AFLC to Headquarters USAF in July 1963, 
based on a DOD directive to implement Military Standard Transportation and Movement Pro¬ 
cedures (MILSTAMP) by October 1963. Approval of this system was granted by Head¬ 
quarters USAF in a letter of 13 November 1963, which directed the collection of MILSTAMP 
intransit data to begin in April 1964 and implementation of the ADPS by July 1964 at the 
Sacramento Air Materiel Area, utilizing the UNIVAC 1050/1 107 scheduled for implementation 
in February 1964. 

In the system implemented in July 1964, the Sacramento Air Materiel Area was receiving 
intransit data cards and transportation control and movement documents and producing five 
transit reports. In May 1965 an additional requirement to provide 11 pipeline reports was 
imposed by Headquarters AFLC with Headquarters USAF approval. The second phase consisted 
of modifications to the Shipment Status Report from the Inventory Management Stock Control 
and Distribution System to prepare the additional reports. This modification increased the 
number of computer runs from 13 to over 30. Implementation of this phase was accomplished 
on schedule in July 1965. 

Due to the size of the development activity (six people), the management procedures 
were quite informal. All progress reporting between the programmers and the project leader 
were informal. The project leader prepared monthly progress reports for AFLC showing 
percentage of completion and man-hours expended. The development and implementation 
were on schedule. 

The system has never been fully documented. All documentation at Sacramento is still 
in rough draft form. The project leader docs most of the documentation with contributions 
from the programmers. AFLC Manual 300-78 will contain the system documentation when 
it is completed. 


SCHEDU LF: 
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DESCRIPTION: Field units submit Transportation Control and Movement Documents (TCMD) 
and Intransit Data Cards (IDC). The TCMD serves as advance notice of a shipment and is used 
primarily for suspense and control. The IDC reflects the history of a shipment. The submis¬ 
sions, which are by card, paper document, and AUTODIN, are stored on magnetic tape for input 
to the computer. On a daily basis, all new TCMD's and IDC's go through a complete data vali¬ 
dation. Erroneous data are recycled to their source for correction, and valid data are placed 
on a master file. Each month, (1) all TCMD and IDC areas are summarized by activity, and 
reports are sent to major air commands and field activity areas to police MILSTAMP pro¬ 
cedures; (2) IDC's and TCMD’s held in suspense are compared to detect delinquent shipments; 
and (3) management reports are produced. 


Transportation Control 
and Movement Docu¬ 
ments (TCMD) and In¬ 
transit Data Cards (1CD) 
Received From 
Field Units 
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WORKLOAD: 


DATA BASE 


Char. In I)aia Baae: 28,680,000 

Pfrcfnt oC Char, on D/A Storage- NA 

Millisecond* of Acre** Time for D/A: NA 

No. of Data Base Record t'ypea 

No. of Data Base Record* 19*1,880 

Pert ••of Growth Rate /Mo. . tlofc 

Char./Mo. of Update Input: 57,88°.OOP 


PROCESSING 

FUNCTIONS 



Key £ U U. 5 


c 

a c 


Char. /Mo. of Input 


Volume: 

57.880.000 

No. of Input Trana* 


action Types: 

3 

No. of Input 


Data Fielda: 

60 

Percent of Input 


Rejects: 

8 




1005. 

90 

80 

70 

60 

50 

40 

30 

20 

10 

0% 



OUTPUTS 




Char . /Mo. of Out 
put Volume: 

No of Output 
» ormata: 

He«|Htnae Time 
(set onda). 


11,950.000 

21 

NA 


Peripheral 



Bate Compute r(«| 

(.umputi 

Total Source Inatrutltona 

24,310 

Unit 

Total Objei t Instruction*: 
Hra. /Mo. of Application 

97.250 

Unit 

Production. 

41 

27 


HARDWARE: 




Univac 1050 


Com - 
pute r 

First 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

('liar. 

Mach. 

Add 

Time 

(us) 

Internal Storage 

Extorr 

Mag Tapes 

tal Storage 

Dm 

Cycle 

lime 

(ns) 

Word/ 

Char. 

Sire 

(bits) 

Wo rd / 
Char. 

Ca¬ 

pacity 

No. 

Mag. 

Tapes 

T rans. 
Rate 

No. 

Disks 

Trans. 

R Mr 

UNIVAC 

1050 

9/63 

Char. 

117 

4 S 

6 

12K 

2 - 

860-2 

8 K to 

1 33K 

None 

UNIVAC 

1107 

9/62 

Word 

4 

4 

36 

32,768 

16- 
850-2 
2 -' * 
851 -3 

8 K to 

1 33K 
25K~t"o* 
I20K 

1 - 

Fl 1-880 

360K 



Comment: The UNIVAC 1050 is used as the peripheral computer while the UNIVAC 1107 
does the main system processing. 


84 






























































































































MILSTAMP Sheet 5 of 7 


SOFTWARE : Software delivered with the equipment by UNIVAC consisted of a COBOL compiler, 
an assembler, hardware diagnostics, debugging aids, an Executive Control System and various 
utility routines. The MILSTAMP system used the following software packages on the UNIVAC 
1050: (1) card to tape; (2) tape to card; (3) tape to printer; and (4) card to printer. On the 
UNIVAC 1107, MILSTAMP used the following software: (1) a sort package; (2) a merge package; 
(3) an Executive Control System; and (4) a COBOL compiler. 

Comment : The Executive Control System provided for automatic sequencing of a scheduled 
set of computer jobs, allocation of memory and peripheral equipment, input/output operations, 
and concurrent processing of 1107 programs. Difficulties experienced with use of the soft¬ 
ware during program checkout were attributed to inadequate documentation. Discrepancies 
in the documentation of the typewriter messages from the Executive Control System presented 
a particular problem. Three UNIVAC programmer /analysts were extremely useful in locating 
software problem areas. 


APPLICATION PROGRAM DEVELOPMENT: The task of developing the system at SMAMA 
was assigned to the System Section oi the Centralized Command Systems Branch within the 
Data Services Division. Hq. AFLC supplied the system specifications from which came the 
system design to provide the required reports. The analyst responsible for the system de¬ 
sign then assigned and supervised the program development effort through to final implemen¬ 
tation. Five programmers were utilized to develop the system and write the programs in 
COBOL. Each program was checked out separately, using dummy test input from the analyst, 
with no formal system test. A 24-hour turn-around was normal during the development period, 
with the programmers being allowed to stand by during their tests to aid the operators in locat¬ 
ing difficulties. The redesign of the system was accomplished to produce 11 more reports and 
accept additional input. Of the original 13 programs, 8 required revision, which tended to re¬ 
duce the system efficiency. Difficulties with the software were experienced during program 
checkout and this was attributed to inadequate documentation. Discrepancies in the documen¬ 
tation of the typewriter output messages from the Executive System presented a particular 
problem. The programmers relied heavily upon 3 programmer/analysts supplied by UNIVAC 
to locate problem areas not locatable from the Executive output. The original system checkout 
used 95 hours on the 1107, and 114 hours on the 1050. The redesigned system checkout re¬ 
quired 100 hours on the 1107, and 200 hours on the 1050. Due to the size of the development 
activity (six people), the management procedures were quite informal. All progress report¬ 
ing between the programmers and the project leader was informal. The project leader pre¬ 
pared monthly progress reports for AFLC showing percentage of completion and man-hours 
expended. These reports were approved by the Branch Chief to whom the project leader made 
periodic informal progress reports. 


FILE CONVERSION: The TCMD and IDC records were used daily as input for creation of 
MILSTAMP tiles. There was no requirement, therefore, for a one-time conversion of 
any records or files. 
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DOCUMENTATION : System documentation has not progressed beyond a draft form. It is 
planned that formal documentation of MILSTAMP will be put into AFLC Manual 300-78. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated 
to System 

In ADP 

In Logistics 

Of College 

Development 

Manager 

1 

1 

9 

4 

4 

Analyst 

1 

1 

9 

4 

U nknown 

Prognmmei 

2 

5 

7 

1.5 

U nknown 

Operations 

Manager 

None 

Unknown 

Unknown 

Unknown 

Unknown 

Operator 

None 

4.5 

U nknown 

Unknown 



OPERATIONS : The computer operation is staffed regularly 8 hours a day, 5 days a week, plus 
any additional time required due to workload. It operates as a closed shop. MILSTAMP is one 
of several applications run on the UNIVAC 1107/1050 computers. A daily schedule is followed 
by the installation. 

Comment : The ‘'Other Time" in the pie chart is manufacturer modification time. 



Prod (Ml I .ST AMP app) 

29 hr. 

Prog Dev * Mt (MILSTAMP app) 
4 hra 1 4 

Pr**d (all other appa) 

204 hra 2H< 


Prog I**v * Mt (all other appa) 
72 hra 10» 

t h* Loat (all other appa) 

1 hra 1 1 

Set lip 
14 hra 2* 



APPLICATION PROGRAM MAINTENANCE : Currently there are two programmers (vacancies 
exist for two more) and one system analyst involved in program maintenance. Eacli of the 
programmers spends 75 percent of his time on MILSTAMP, with 50 percent for the analyst. 
Much of the programming maintenance activity is developing programs and procedures for 
special reports required by Headquarters USAF. In 1965, 30 such reports were produced. 
Program corrections and improvements take up the remainder of the time. 
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Comment: None. 
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BENEFITS : Proposed: DOD directed all DOD agencies to implement MILSTAMP procedures. 
The Air Force MILSTAMP Central Data Collection System at the Sacramento Air Materiel Area 
was proposed to supply data on all AF transportation activities to the Defense Supply Agency 
(DSA). DSA was to be responsible for consolidating transportation information from all DOD 
agencies. Benefits to result from MILSTAMP implementation were to include the capability 
to establish standard transit and hold times, permitting an evaluation of military and civilian 
carrier performance. Further benefits were reduction in pipe-line times, resulting in reduc¬ 
tion in materiel inventories. 

Actual: MILSTAMP potential benefits have been affected by lack of response from consignor' or 
consignees and a high error rate from those who have responded. Since implementation, re¬ 
sponse has continually improved and the error rate gradually reduced due to education and ag¬ 
gressive policing action. 


COST FACTORS: 


Man-Months of Development Effort (Dev.) 


Proposed: UnkCZ 

Actual: 61MBMHMHMH 

Comment : The DAP prepared Cor MILSTAMP did not state the man- 
months that would be required for Initial development of the system. 

It did state, however, that two analysts and three programmers would 
be provided for Initial program development from existing AFLC re¬ 
sources. A major redesign of MILSTAMP, called Phaje II develop¬ 
ment, was accomplished In the period May to July 1965. Ten actual 
man-months of development effort were needed for Phase II. The 
actual number represents both Phase I and Phase Q development efforts. 

Months of Elapsed Development Time (Dev.) 

Proposed: 7 [ 1 

Actual: 

Comment : A letter from Hq. USAF approving the AFLC DAP for 
MILSTAMP stated that MILSTAMP would be operational not later 
than 1 July 1964. Many problems were experienced with the soft¬ 
ware during Initial Phase I program checkout because of Inadequate 
documentation. It is believed that this factor contributed signifi¬ 
cantly to the 1-month schedule slippage. The actual number shown 
here reflects the 8 months elapsed for the Initial Phase I develop¬ 
ment and the 3-month Phase 11 development. 

Dollars of Hardware Cost for Program Checkout (Dev.) 
Proposed: UnkCZ 

Actual: 70,847 

Comment: Program checkout for Phase I development occurred during 
the period 17 March to 31 July 1964. Program checkout for Phase I 
required 95 hours on the UNTVAC 1107 computer and 114 hours on the 
UNIVAC 1050 computer. Phase 11 program checkout was accomplished 
In the period May to July 1965, when 2-1/2 hours each day were al¬ 
located to program checkout. Phase 11 program checkout required 
100 hours on the UNIVAC 1107 and 200 hours on the UNIVAC 1050. 

The actual cost shown here Is for both Phase I and Phase O. 


Hours/Month of Hardware Use for Application Production (Op.) 

iProposed: Unk f~7 

Actual: 41 

Comment: The actual number reflects usage during March 1966 on the 
Uf'UV'Afi 1107. Twenty-nine hours were used for MILSTAMP application 
production on the peripheral UNTVAC 1050. 

Hours/Month of Hardware Use for Program Maintenance (Op.) 

Proposed: Unk CZ 

Actual: 6 

Comment: The actual number reflects usage during March 1966 on ths 
UNTVAC 1107. Four hours were used for MILSTAMP program mainte¬ 
nance on the peripheral UNIVAC 1050. 

Number of Operations Personnel (Op.) 

Proposed: Unk CZ 

Actual: 4.5 

Comment : The DAP for MILSTAMP stated a proposed number of 31 oper¬ 
ators on the basis of a normal 24-hour, 7-day week operation. The actual 
number of personnel Is prorated from 24 operators based on machine hours 
for MILSTAMP. 

Number of Program Maintenance Personnel (Op.) 

Proposed: Unk CZ 

Actual: 2 

Comment : The actual number of personnel Is prorated from 2 programmers 
and 1 analyst based on time spent on MILSTAMP program maintenance. 

Dollars/Month of Hardware Cost (Op.) 

Proposed: Unk CZ 

Actual: 18,280 ■■■■■ 


Comment: None. 


FUTURE PLANS: Currently, there are no plans to make any major improvements in the 
programs or the system. There is a requirement, however, that MILSTEP be implemented 
1 October 1966. There is also some discussion that DOD would like SMAMA to become the 
central collection agency for all DOD activities. It is estimated that this action would re¬ 
quire 13 new processing runs and modification to 8 of the current MILSTAMP runs. 
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SYSTEM : Missile Simulation--MISSIM (IBM 7094) 


DATA SYSTEM DESIGNATOR: B154 and B276 


DATA COLLECTION DATE: April 1966 


Contact for Additional Information 

Data Systems and Statistics 

Mathematical Services Laboratory 

Eglin Air Force Base 

Valparaiso, Florida 

Development 

Air Proving Ground Center 

Eglin Air Force Base 

Florida 

Maintenance 

Air Proving Ground Center 

Eglin Air Force Base 

Florida 

Pilot Installation 

None 

First Operational Installation 

Air Proving Ground Center 

Eglin Air Force Base 

Florida 

Number of Operational Installations 

1 


FUNCTION : The users of MISSIM are the Deputy for Test Operations and the Deputy for Effec¬ 
tiveness Test, Air Proving Ground Center of the Air Force Systems Command. The mission 
of the users is to conduct and evaluate Air Force weapons effectiveness tests. MISSIM functions 
as a research and development support system to simulate the firing of one or more ground-to- 
air missiles at an aircraft target for purposes of determining the closest approach of the mis¬ 
siles to the target. The flight path of the target is described with data from a control radar 
tracking an actual aircraft flying a simulated sortie. 


ORGANIZATION: 



(An&lyat and Immediate Uaer) (Analyst) (Frogt ammei ) (Operator) 
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HISTORY : Informal discussion at the Air Proving Ground Center (APGC) between the user (Dep¬ 
uty for Test Operations) and the developer/operator (Mathematical Services Laboratory) re¬ 
sulted in a letter dated 14 February 1963, directing the Mathematical Services Laboratory to 
produce "a missile simulation and target track comparator program'' for the IBM 7094. The 
specifications for the desired programs likewise grew from informal discussions and meetings. 

The first target track comparison program became operational in August 1963 and the 
first missile simulation program became operational in September 1964. Because the physical 
characteristics of the guidance radar and the missile be ing* simulated have changed continually, 
the Missile Simulation development has been marked by continually evolving programs. When 
the program changes become extensive on a cumulative basis, the Mathematical Services L?J - 
oratory rewrites the entire program. 

Until August 1965, the Missile Simulation suffered from a relatively low priority compared 
with other APGC projects. Since that time, events exterior to APGC have caused the simulation 
to enjoy a high priority. 

The communication flow from user to project mathematician to programmer was rigidly 
adhered to. There was virtually no skipping of rungs on the communication ladder. The project 
mathematicians acted in a coordinator/analyst role between the user and programmer, prin¬ 
cipally for the more technically oriented radar and missile portions of the simulation. Communica¬ 
tion between the user and analyst was infrequent, whereas communication between the analyst 
and programmer occurred daily. There was no comprehensive system design document. 

The Missile Simulation inputs and outputs are classified, as are the particular technical 
characteristics of the equipment being simulated. The initial analysis was somewhat hindered 
by these security factors, resulting in a delay in development. 


SCHEDULE: 
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DESCRIPTION: The firing of one or more ground-to-air missiles is simulated to determine the 
closest approach of the missiles to the target. Actual target track data are gathered at APGC 
test ranges by fl* ; ing simulated missions with actual aircraft. Two radars collect data: a con¬ 
trol radar with pre-established accuracy and an experimental missile guidance radar. 


Real Tima Evanta 
al APGC P ange • 


N«>n-Raal 1 !<na Evanta al 
Mathamati* al Sarvltea laboratory 


s' 

Simulation 

Pa rimrlr ra 
Control f'arH* 



Simulati 
of Mlaai 
1 argat 

i 1(ring 
ila at 



Raport 


To Projact 
Mathamatlc I an 
(or Validation 
of Radar Data 


Report 


to Uaar for 
Evaluation of 
Mlaaila 
Effactlvanaaa 



1 o Projact 
Mathamatlclan 
for Validation of 
Radar Data 


• r«il ait«l li.ii.l 



an.* P.tr 



(••rtu ‘.tatlati« al 


po 

Aiutlyaia 
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WORKLOAD: 


PROCESSING 

FUNCTIONS 


Char. /Mo. of Input 

Volume: 

77,540,000 

No. of Input Trans¬ 

|2 (data): 

action Types: 

15 (control) I 

No. of Input 

115 (data); 

Data Fields: 

|525 (control) 

Percent of Input 

Rejects: 

Unk 




- s c 

^ a s 

Key 5W US <5 


! L 

O * f 

o «:o 


I oof* 
90 
80 



Total Source Instructions: 21,180 

Total Ohjei t Instructions: 84,000 

l(rs./M<». of Application 
Production: 67 


Unk 

Unk 


Char. /Mo. of Out¬ 


put Volume: 

47,130.000 

No. of Output 


Formats: 

39 

Response Time 


(seconds): 

NA 


HARDWARE: 



IBM MO 1 
Number 1 


IBM 1401 
Number 2 


Com¬ 

puter 

First 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(us) 

Internal Storage 

External 

Storage 

Peripheral Devices 

Card Reader/Punch 

Printer 

Cycle 

Time 

(us) 

Word/ 

Char. 

Size 

(bits) 

Word/ 

Char. 

Ca¬ 

pacity 

No. 

Read 

Speed 

(cards/ 

min) 

Punch 
Speed 
(cards/ 
min) 

No. 

Speed 

(1pm) 

No. 

Mag 

Tapes 

Trans. 

Rate 

IBM 

7094-11 

4/64 

Word 

1.4 

1.4 

36 

32K 

21 - 

729 VI 

22.5K- 
62. 5K 

1- 

711 

250 

100 

1- 

716 

150 

IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

4K 

2- 

729 

22.5K- 
62.5K 

1 - 
1402 

800 

250 

1 - 

1403 

600 

IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

8K 

2- 

729 

22.5K- 

62.5K 

1 - 
1402 

800 

250 

2- 

1403 

600 


Comment: Due to a stauration condition on the large computer a second IBM 7094-11 
has been delivered recently. 
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SOFT WAR E : Software for the IBM 7094 consisted of an IBSYS Executive Monitor, a FORTRAN 
IV compiler, and a FAP assembler. The software was delivered by IBM with the equipment in 
April 1966. 

Comment : The only shortcoming of the software was the inability of IBSYS to handle real-time 
inputs. 


APPLICA TION PROGRAM DEVELOP MENT : The communications between user, project math- 
ematician, analyst, and programmer were well defined by management. The user interfaced 
only with the project mathematician or analyst who in turn interfaced with the programmer. 
Communication between user and analyst was infrequent and informal, while communication 
between analyst and programmer was informal with little documentation. There was no com¬ 
prehensive system design document. The programming effort, conducted at the Mathematical 
Services Laboratory, utilized an existing IBM 7090 (later 7094) computer configuration. Three 
concurrent programming activities proceeded during development: (1) writing new programs to 
reduce the raw data from the guidance radar; (2) modification of existing data reduction and 
comparative programs to accept a new type guidance radar data; and (3) programming the mis¬ 
sile simulation program itself. The programs, written in FORTRAN IV and FAP assembly lan¬ 
guage, were checked out individually and not as a system due to their extreme independence. 
Checkout of the simulation program was hampered by lack of radar data tapes. Records of 
program development hours were not kept. The programmers documented their programs when 
they became operational. 


FILE CONVERSION: No file conversion was involved in MISSIM development. 
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DOCUMENTATION : Design documentation was limited; communication occurred on an informal 
basis between analyst and programmer. At the time of initial operation, the programmer created 
user documentation on punched cards, which could be updated or listed easily. There was no 
detailed program documentation. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
System 

In ADP 

In Scientific 
Computation 

Of College 

Development 

Manager 

1 

1 

1S.0 

1S.0 

4.0 

Analyst 

2 

2 

12.0 

11.0 

5.0 

Programmer 

3 

3 

6.0 

6.0 

4.0 

Operations 

Manager 

1 

0.3 

10.0 

9.0 

2.0 

Operator 

0 

2.1 

Unknown 

Unknown 



OPERATIONS : 
a closed shop. 


The computer operation is staffed 24 hours a day, 7 days a week. It operates as 
MISSIM, which is run 26 times per month, is one of many applications run on the 
IBM 7094/1401 (A and B) computers. IBSYS controls operations on the IBM 7094 90 percent of 
the time, doing stacked jobs. Scheduling is on a "first come, first served” basis, with priority 
consideration. A 50 to 150-hour backlog normally exists. 

Comment : Excellent hardware reliability is reflected in low machine maintenance times. It was 
not possible to determine the "other time" origin, but it was most likely "off time." 


Off M hr* S% 
Schd Mt 2 hr* 1% 

M*ch Error Lost 
2 hr* 1% 

Idle 20 hr* 3% 
Set Up 2Shr* 4% 

Chg Lo*t (all 
app*)21 hr■ )% 

Prog D«v ft Mt 
(all other app*) 
38 hr* 3% 



Prod (MISSIM 
*pp) 67 hr* 9% 


Prog Dev A Mt 
(MISSIM app) 

3 hr* 1% 

Prod (all other 
appa) 498 hr* 
68 % 



Idle 

32 3 hr* 44% 


Prod (MISSIM 
• pp) 26 hr* 4% 

Prog Dev A Mt 
1 hr 1% (MISSIM app) 


Prod (all other 
• pp*) 202 hr* 28% 

Prog Dev A Mt 

18 hr* 2% (all other app*) 

Chg Lost (all 
■pp*) 3 hr* 1% 


IBM 1401 (A) 



Prod 

(MISSIM app) 
37 hr* 5% 


Prod 

(all other app*) 
280 hr* 38% 


APPLICATION PROGRAM MAINTENANCE: The application program maintenance effort is es¬ 
sentially a continuation of the application program development effort. The development ana¬ 
lysts and programmers are also the maintenance analysts and programmers and the same in¬ 
formal methods of communication among user, analyst, and programmer are used. 

Comment: The program maintenance effort is relatively large because the characteristics of the 
guidance radar and missile being simulation have changed continually. Also, the users continu¬ 
ally impose new requirements in the simulation capability. Programs are completely rewritten 
when accumulated changes become extensive. 
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BENEFITS: Proposed : The primary benefit from MISSIM was planned to be a system for missile 
simulation and target track comparison. 

Actual: A system of programs has enabled MISSIM users to simulate the flight of one or more 
ground-to-air missiles at an aircraft target for the purpose of determining the closest approach 
of the missile to the target. This represents a capability not formerly available to users at 
APGC. No cost saving figures are available, since these computations were not made prior to 
MISSIM. 


COST FACTORS: 


Man-Months of Drvflopmrnt Effort (Dyv.) 

Proposed: Unk CZ 

Actual: 66 

Comment : No formal proposal was prepared for MISSIM. The project 
germinated from informal discussions between PGO (user) and PGM (de¬ 
veloper). These discussions resulted In a letter from PGO to PGM dated 
14 February 1963 requesting that "a missile simulation and target track 
comparator program* be developed for the IBM 7094 computer. Even 
though the user did not rigidly specify the system characteristics to the 
developer, continued Informal Interaction resulted in a system that 
satisfies the current user needs. 

Months of Elapsed Development Time (Dev.) 

Proposed: 4 Q 

At Inal: )t ■■■■■■HI 

Comment: The user, PGO, made the request in their letter to the de¬ 
veloper, I’GM, for a 15 June 1963 initial capability. It became apparent 
that this date was unrealistic, and it was disregsrded. The actual num¬ 
ber ol months shown here Is from 14 February 1963 to the current date. 

Dollars of Hardware Cost for Program Checkout (Dev.) 

Proposed: Unk CZ 

Actual: Unk V 

Comment : Records of computer hours by program were not kept before 
December 1964. Some programs on which records were kept after that 
date had more than one application. Other development costs not included 
were 'or checkout runs performed to assist engineers in checkout of hard¬ 
ware changes. These factors make it impossible to determine MISSIM 
program checkout hours. 

Ifours/Month of Hardware Use for Application Production (Op.) 

Proposed: Unk CZ 

Actual: 67 ■■■■■■■■■■■ 

Comment: The actual number reflects usage during March 1966 on the 
IBM 70${. Sixty-three hours were used for MISSIM application production 
on the peripheral IBM 1401 computer. 


Hours/Mon t h of Hardw ar e Use fo r Program Maintenance (Op.) 
Proposed: Unk □ 

) HMMHi 

Comment : The actual number reflects usage during March 19f<6 on the IBM 
7094. One hour was used for MISSIM program maintenance on the periph¬ 
eral IBM 1401 computer. 

Number of Operations Personnel (Op.) 

Proposed: Unk CZ 

Actual: 1 

Commenl : Tlie actual number of personnel is prorated from li. people on 
the basis of machine liuurs for MISSIM 

Num ber of Program Maintena n ce Personnel (Op.) 

Proposed: Unk CZ 

Actual: .«! 

Comment ; The actual number of pernonnel Is prorated from three program¬ 
mers, Iwo analysis, and one manager onihe basis of lime devotrd tnMlSSIM 
program maintenance, ( or rent programming activity la considered to he 
more closely related to program development than program maintenance 
because of the riuitinual'y evolving development of MISSIM programs. 

Doll ■ > r s / Mouth of H a rdware Cost (Op.) 

Proposed: Unk CZ’ 

Mi■■■■ 

Comment; None 


FUTURE PLANS : MISSIM undergoes continual modification to reflect changes in the guidance 
radar inputs and missile parameters. Currently, a new Rigid Body Program, No. 827, is being 
checked out by Lockheed, Sunnyvale, the program’s developers, at the Mathematical Services 
Laboratory. This program is functionally equivalent to two existing programs, nos. 595 and 
708, in that it accepts both real and theoretical flight data. Program 827 al.so includes new auto¬ 
pilot equations and equations of motion. The majority of output reports from program 827 are 
in the form of graphs produced on the Stromberg-Carlson 4020 microfilm recorder. It is un¬ 
likely that program 827 will completely replace 595 and 708 since it requires four times as much 
computer time as 595 or 708. Program 595 is thus being modified to output on the SC 4020 in the 
same manner as 827. Lockheed also is developing a program, no. 802, to produce aircraft 
flight data which will be input to 827 in the theoretical mode of operation. 
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SYSTEM: Orbit Determination and Analysis--ORBIT (IBM 7044) 


DATA SYSTEM DESIGNATOR: B011 


DATA COLLECTION DATE: May 1966 


LOCATION: * 


Contact for Additional Information 

Data Analysis Branch 

Technical Services Division 

Air Force Cambridge Research Labs 
Hanscom Field, Bedford, Massachusetts 

Development 

Air Force Cambridge Research Labs 
Laurence G. Hanscom Field 

Massachusetts 

Maintenance 

Air Force Cambridge Research Labs 
Laurence G. Hanscom Field 

Massachusetts 

Pilot Installation 

None 

First Operational Installation 

Air Force Cambridge Research Labs 
Laurence G. Hanscom Field 

Massachusetts 

Number of Operational Installations 

1 


FUNCTION : The users of ORBIT are the various laboratories (Aerospace Instrumentation, Data 
Sciences, Meteorology, and other) of the Air Force Cambridge Research Laboratories. The 
mission of the users is to conduct basic and applied research in the environmental sciences and 
in certain areas of the physical sciences. ORBIT functions as a research and development sup¬ 
port system to accurately determine earth satellite orbits by the minimum variance method. 


ORGANIZATION: 



(D*v«lop«r) 
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HISTORY : The various laboratories at the Air Force Cambridge Research Laboratories 
(AFCRL) have the authority to contract out individually for support in their missions if no capa¬ 
bility exists in-house. Several requests for support prompted the Data Analysis Branch of the 
Technical Services Division to ask approval to develop a general orbit determination and analysis 
system. By creating this capability within the Technical Services Division, duplication of effort 
would be avoided. Approval from the Technical Services Division was granted in January 1964. 

A 1-year contract was let to the Martin Company in May 1964 to develop the mathematical ap¬ 
proach and to verify it with an operational set of computer programs. At the end of this initial 
contract period, the report on the mathematical method was published and the contract was 
renewed. The computer programs were improved and the rest of the documentation produced. 
May 1966 is considered the operational date, but a usable system of limited capability existed in 
early 1965. 

The contract was monitored by a member of the Data Analysis Branch. This contract re¬ 
quired very little supervision since it was estimated that only 5 percent of the monitor's time was 
actively taken with this responsibility. Since the analysis, programming, and checkout were 
performed on-site, daily communication was possible between the contractor and AFCRL on an 
informal basis. On an official basis, the contractor was required to submit quarterly progress 
reports. 

Complete maintenance and user documentation were published in May 1966. 


a 

/ 


SCHEDU LE: 



96 






















































































































































ORBIT Sheet 3 of 7 


DESCRIPTION: This system performs the accurate determination of earth satellite orbits by the 
minimum variance method. Input consists of lead control cards followed by observation cards 
(usually from SPADATS). After the lead cards are interpreted, the observation cards are loaded 
onto the disk to be read when needed during the main processing. A print tape is produced con¬ 
taining ephemeris data as well as a binary history tape which is used for further analysis by 
other programs. 


Normally 

From 

SPADATS 


AFCRL 
Project 
Personnel 
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WORKLOAD: 


PROCESSING 

FUNCTIONS 



HARDWARE: 




IBM 7044 IBM 1460 


Com¬ 

puter 

Flret 

Dellv- 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(u») 

Internal Storage 

External Device. 

Peripheral Device. 

Card Reader/Punch 

Printer 

PT Reader/Punch 

Mag Tape. 

Dlak 

Cycle 

Time 

(u») 

Word/ 

Char. 

SUe 

(bit.) 

Word/ 

Char. 

Ca¬ 

pacity 

No. 

Mag 

Tape. 

Tran., 

Rate 

No. 

Disk. 

Trane. 

Rate 

(char./ 

aec) 

Char. 

Ca¬ 

pacity 

Ac¬ 

cess 

Time 

(m.) 

No. 

Read 

Speed 

(card./ 

min) 

Punch 

Speed 

(card. 

/min) 

No. 

Speed 

(1pm) 

No. 

Read 

Speed 

[char./ 

min) 

Punch 
Speed 
(char. / 
min) 

IBM 

7044 

7/63 

Word 

5 

2.5 

36 

32K 

5- 

729 V 

to 

60K 

1301-1 

90.100 

27,960, 

000 

180 

None 

... 

... 

None 

... 

None 


... 

IBM 

1460 

10/63 

Char. 

108 

6 

6 

8K 

1- 

729 V 

to 

60K 

None 

— 



1402-3 

800 

250 

' 

1- 

1403-3 

1,100 

1012 

500 

150 


Comment: The ORBIT system was initially developed for an IBM 7090 system. Time 
on the IBM 7090 was rented from a service bureau. 
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SOFTWARE : Software for the IBM 7044 supplied by IBM included an IBSYS executive system 
which has FORTRAN IV and COBOL compilers, and MAP and BAP (a subset of MAP) assem¬ 
blers. Software packages also used are the SHARE program library packages, the IBM- 
distributed program library, a FORTRAN IV computer system library, and the IBM scientific 
subroutine package for System 360 which was converted to the IBM 7 044. 

Comment : Since the application programs were originally written partially in FAP for the IBM 
7 094, they had to be converted to run in MAP on IBSYS. Two people are involved in maintenance 
of the software. 


APPLICATION PROGRAM DEVELOPMENT : Analysts from the Martin Company produced func¬ 
tional flow charts at the subroutine level and described the sequence of computation. The de¬ 
tailed programming problems were left to the programmers. The initial set of operational 
programs was written in FORTRAN II for an IBM 7090 by Martin Company programmers at 
AFCRL. They were subsequently redesigned for an IBM 7044 configuration which required the 
following: (1) segmentation of programs due to the large size of the IBSYS monitor; (2) redesign 
to take advantage of the disk on the 7044 configuration; and (3) coding changes caused by certain 
inconsistencies between the 7090 FORTRAN II and 7044 FORTRAN IV languages.. Since the anal¬ 
ysis, programming and checkout were performed on site, daily communication was possible 
between contractor and AFCRL, represented by the Data Analysis Branch, on an informal basis. 
The contractor was required to submit quarterly progress reports. Thirty-one programs make 
up the ORBIT system. Ten are written in FAP, the rest in FORTRAN IV. Sixty-seven hours of 
computer time were required for program checkout. Thirty-three of these hour4 were on the 
IBM 7044 and 34 hours were on the IBM 7090. Three checkout runs per day on the 7044 to one 
per day on the 7090 were possible, with the programmers allowed to observe their runs if 
desired. 


FILE CONVERSION: No file conversion was involved in ORBIT development. 
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DOC U M E N T ATI ON : "Orbit Determination and Analysis by the Minimum Variance Method" 
(AFCRL 65-579), a document describing the technical approach taken in the development of the 
system, was published in August 1965. Informal user documentation and program listings were 
available in early May 1966* followed by complete maintenance and user documentation later 
that month. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
System 

In ADP 

in Scientific 
Computation 

Of College 

Development 

Managor 

1 

1 

8.0 

8.0 

4.0 

Analyst 

1 

1 

8.0 

8.0 

7.0 

Programmer 

2 

2 

4.0 

4.0 

5.0 

Operations 

Managor 

6 

0.0 

11.0 

11.0 

4.0 

Operator 

12 

0.1 

6.0 

6.0 



OPERATIONS: The computer operation is staffed as required. Current workload normally re- 
quires staff 24 hours a day, 7 days a week. It operates as a closed shop. ORBIT is one of many 
applications run on the IBM 7044/1460 computers. All jobs are run under the IBSYS monitor. 
ORBIT runs an average of six times a month. Only express runs, up to 5 minutes and 50 pages 
of printed output, are run during normal working hours. 

Comment : Excellent computer reliability is reflected in the low machine maintenance times. 


Off 

60 hi 

Sch 
10 hi 

Mach Error 
1 1 


42 ti 

Chg Loat (all 

7 hri 

pTogDov* Mt(all othar aj 

1 hi . r 

Off 

64 hra <*. 

Schd Mt 
12 hra 2% 

Mach Error Loat 
I hr I* 

Unachd Mt 
2 hra 1% 

Idle 

343 hra 43% 

IBM 1460 


APPLICATION PROGRAM MAINTENANCE : The ORBIT system does not require much mainte¬ 
nance. A new atmospheric model is inserted each year and modification in support of particular 
satellite programs is very infrequent. Maintenance is done by the developers, the Martin 
Company. 

Comment : The small requirement for program maintenance arises from the fact that the system 
has been operational for a relatively long period of time. 
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BENEFITS : Proposed : The primary benefit from ORBIT was planned to be an orbit determination 
and analysis capability, which had not existed in the past. This capability was to be available to 
any division within AFCRL, and therefore had to be general in nature. The basic analytic tech¬ 
nique to be used in the orbit determination was the method of minimum variance. 

Actual: ORBIT provides the orbit determination and analysis capability that was required. It 
may be assumed that a considerable saving in elapsed time and personnel costs (over manual pro¬ 
cedures) was realized with the implementation of ORBIT. 


COST FACTORS: 


Man-Months of Development Effort (Dev.) 

Proposed: UnkCZ 

Corwnent : An RFP was sent oat tn January 1964 with approval by the 
Technical Services Division at AFCRL. A "cost-plus" contract was 
awarded in May 1964 to Martin Co. for work to start 1 June 1964. There 
were no detailed task statements tn the contract. The actual number of 
man-months shown here reflects what has been expended to date. 

Months of Elapsed Development Time (Dev.) 

Proposed: Unk CZ 


Comment : The initial contract awarded to Martin Co. was for 1 year. 
The contract was renewed for another year and is currently scheduled 
to end 1 June 1966. The actual number of months shown here reflects 
both contracts. 

Dollars of Hardware Cost for Program Checkout (Dev.) 


Proposed: Unk CZ 

Actual: 18.0S0 ■■■■Hi 

Comment : Program checkout has required to date 34 hours on the IBM 
7090 and 33 hours on the IBM 7044. The actual cost shown here Is for the 
hours used on both the IBM 7044 and the IBM 7090. 

Comment : None. 

Hour./Month of Hardware Use for Application Production (Op.) 

Proposed: Unk CZ 

I 

Comment : Reflects usage during March 1966 on the IBM 7044 com* 
puter. The IBM 1460 was not used for ORBIT. 


FUTURE PLANS : The Computer Processing Branch at AFCRL hopes to augment the present 
computer system to an IBM 7094/7044 coupled system to alleviate the overloaded condition now 
in existence. This will not affect the ORBIT system. There are no design changes contemplated 
for ORBIT system programs. 


Houra/Month of Hardwara Uss for Program Maintenance (Op,) 

Proposed: UnkCZ 

Actual: 01 

Comment : Reflects usage during March 1966 on the IBM 7044 computer. 
The IBM 1460 was not used for ORBIT. 

Number of Operations Personnel (Op.) 

Proposed: UnkCZ 

Actual: 0.1 

Comment : The actual number of personnel is prorated from 12 operators 
and 6 managers on the basis of machine hours for ORBIT. 

Number of Program Maintenance Personnel (Op.) 

Proposed: UnkCZ 

Actual: 01 

Comment : None. 

Dollars/Month of Hardware Cost (Op.) 

Proposed: Unk CZ 
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SYSTEM : Priority Distribution System--PDS (RCA 301) 


DATA SYSTEM DESIGNATOR: D032A 


DATA COLLECTION DATE: April 1966 


Contact for Additional Information 

Comptroller (Data Management Division) 
Headquarters, Air Force Logistics Cmd. 
Wright-Patterson Air Force Base 

Dayton, Ohio 

Development 

Headquarters, Air Force Logistics Cmd. 
Wright-Patterson Air Force Base 

Ohio 

Maintenance 

Headquarters, Air Force Logistics Cmd. 
Wright-Patterson Air Force Base 

Ohio 

Pilot Installation 

None 

First Operational Installation 

San Antonio Air Materiel Area 

Kelly Air Force Base 

Texas 

Number of Operational Installations 

7 


FUNCTION : The users of PDS are seven AFLC Air Materiel Areas--SAAMA, SMAMA, 
OCAMA, MAAMA, OOAMA, WRAMA, and MOAMA, The mission of the users is logistic and 
system support management for specific weapon systems. PDS is a subsystem of the Inventory 
Management Stock Control and Distribution System and functions as a management support sys¬ 
tem to provide for the expeditious processing of high-priority requisitions and associated trans¬ 
actions received from Air Force bases, AFLC AMA's and contractors, Defense. Supply Agency, 
Military Assistance Program, and other DOD and U. S. Government agencies. 


ORGANIZATION: 



(On-*ite Syitem Malnt«n*nc«) (Operator) 
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HISTORY : In I960 the Air Force Logistics Command (AFLC) established the Inventory Manage¬ 
ment Stock Control and Distribution (IMSC&D) System for the stock control and distribution func¬ 
tion at all AFLC depots on the IBM 7080. This system gave a 12- to 24-hour response to the 
customer's request, with emergencies handled manually. Changes in operational concepts and 
requirements, however, increased the demand for faster response. AHeadquarters, USAF, task 
group recommended that AFLC formulate plans to implement a standard depot inventory manage¬ 
ment package with random access and rapid response for supply distribution data handling. 

AFLC proposed to acquire a small-scale random access computer to be used in conjunction with 
the IBM 7080 to process priority transactions as received, but later decided a separate priority 
processing system should be developed which would operate in conjunction with the present 
IMSC&D. The development of this system (PDS) could satisfy the desired processing time cri¬ 
teria with a minimum of cost. This concept was accepted by Headquarters USAF and approval 
was given for development and implementation of the system. 

Program development of PDS took place at Headquarters, AFLC and was distributed as a 
package to the Air Materiel Areas using the system. Within the AFLC Data Center, adata systems 
project office directed the analysts and programmers in the PDS development. This office de¬ 
veloped the detailed system design under the specifications set forth by the Data Management 
Division, AFLC. While the detailed system was being designed and approved by the Data Man¬ 
agement Division, training was being conducted at Headquarters AFLC for analysts, program¬ 
mers, and operators. During the development phase, relatively minor changes were required 
in the system design for MILSTAMP requirements. The PDS is currently undergoing system 
design modifications and a complete reprogramming effort in order to incorporate new process¬ 
ing requirements imposed by Department of Defense MILSTRAP procedures. 

The documentation for the PDS is contained in one manual, AFM 300-20. There are no sep¬ 
arate operator's, user's, or programmer's manual. The program maintenance function is car¬ 
ried on at the AFLC Data Center and any program changes or modifications require changes in 
AFM 300-20. 

PDS is operational at the following seven sites: San Antonio AMA, Sacramento AMA, 
Oklahoma City AMA, Ogden AMA, Warner Robbins AMA, Mobile AMA, and Middletown AMA. 


SCHEDULE: 
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DESCRIPTION: Each day the PDS loads, via punched cards and magnetic tape, the Data Disk 
File with the tables and records necessary to process high-priority supply transactions. Supply 
transactions are edited to validate elements of data. Those transactions which are valid are 
core memory transmitted to the other processor, where documents are prepared for output. At 
the completion of the daily run, the data records are retained on magnetic tape for the next cycle 
of the system. 
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WORKLOAD: 


DATA BASE 

Char. In Data Baee: 

116.400.000 

Percent of Char, on D/A Storage: 

100 

Millisecond* of Accee* Time for D/As 

79 

No. of Data Bate Record Type*: 

• 

No. of Data Base Record*: 

169.300 

Percent Growth Rate /Mo.: 

Unit 

Char. /Mo. of Update Input: 

4.390.000 


INPUTS 


Char /Mo. of Input 
Volume: 

No. of Input Trane* 
action Types: 

No. of Input 
Data Tlelde: 
Percent of Input 
Rejects: 



Char. /Mo. of Out¬ 


put Volume: 

9,590.000 

No. of Output 


Format*: 

20 

Response Time 


(seconds): 

NA 


HARDWARE: 
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SOFTWARE : The only software for the RCA 301's supplied and required is the symbolic assem- 
bly language assembler which was developed specifically for this system due to the unusual 
hardware configuration. 

Comment : Although other software is available for the standard RCA 301 configuration, this 
software will not operate on the dual processor PDS configuration. Sufficient need did not exist 
for this software to warrant conversion for the PDS configuration. A number of errors were de¬ 
tected in the assembler while checking out PDS application programs. These errors occurred 
primarily because the assembler was written concurrently with application program development. 


APPLICATION PROGR AM DEVELOPMENT : A data systems project office was established 
within Hq. AFLCData Center to direct programmers and analysts on the development of PDS. 

A detailed systems design was developed by this office and approved by the Data Management 
Division of AFLC, which had supplied the specifications. The programmers had continual access 
to the RCA 301 for the checkout of PDS. Many of the problems encountered during the develop¬ 
ment phase can be attributed to the fact that the programmers and RCA personnel, including 2 
programmers, were inexperienced in the dual processor computer configuration. Program 
documentation was a joint effort of analysts and the responsible programmer. The 21 programs 
were written in RCA symbolic assembly language. Monthly progress reports on percentage of 
completion and man-hours expended were prepared by the project office and submitted to Hq. 
AFLC. The dual processor configuration necessitated the creation of an unusual programming 
technique to allow one processor to verify transactions while the other processor is formatting 
and producing the output products. System design changes during development, such as addi¬ 
tional transaction types, did not significantly affect the implementation schedule. 


FILE CO N VERSION: The IMSC and D records are used daily as input for creation of the priority 
distribution system records. There was no requirement, therefore, for a one-time conversion 
of any records or files. 
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DOCUMENTATION : All system documentation is contained in Air Force Manual AFM300-20. 
There are no separate operator, user, and programming manuals. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
System 

In ADP 

In Logistics 

Of College 

Development 

Manager 

3 

3 

8.0 

6.5 

2.0 

Analyst 

6 

6 

5.5 

5.0 

Unknown 

Programmer 

9 

9 

7.0 

1.5 

Unknown 

Operations 

Manager 

None 

Unknown 

Unknown 

Unknown 

Unknown 

Operator 

6 

10 

Unknown 

Unknown 



OPERATIONS : The computer operation at SMAMA is scheduled for processing and report gen¬ 
eration 18 hours per day, 7 days per week. Three hours each per day are allotted to loading/ 
unloading of PDS and to preventive maintenance. A daily schedule is utilized by SMAMA. 



APPLICATION PROGRAM MAINTENANCE : There are currently seven programmers involved in 
full-time program maintenance at Headquarters AFLC and two programmers at SMAMA devoting 
7 5 percent of their time to PDS. Information concerning the number of maintenance program¬ 
mers at the other AMA'swasnot available. Because of disk problems, some of the programs 
are being rewritten to provide automatic restart/recovery procedures with more elaborate disk- 
read checks and edits. A second current program maintenance activity is reprogramming to 
include back orders on the PDS master file. Headquarters AFLC and SMAMA, together, have 
six system analysts working on PDS program maintenance. They are currently involved in sys¬ 
tem design modifications to incorporate new processing requirements imposed by DOD 
MILSTRAP procedures. 

Comment: None. 
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BENEFITS : Proposed: PDS was proposed to handle the high-priority requests that could not be 
handled by the Inventory Management Stock Control and Distribution System. By 1963, approxi¬ 
mately 40 percent of the total requests submitted required rapid response. 

Actual: Through the use of direct access storage devices, PDS was able to provide the required 
response time at a minimum cost. 


COST FACTORS: 



Man-Months of Development Effort (Dev.) 

Proposed: 

Unk CZ 

Actual: 


Comment: No 
in rcaponae to 
mutated detail 

formal DAP was prepared for PDS. The system developed 
the recommendation of a Hq. USAF task group which for- 
plans and programs for the implementation of PDS. 


Months of Elapsed Development Time (Dev.) 

Proposed: 

161_1 

Actual: 



Comment: The schedule slippage was due to » delay in equipment selec- 
tion and the fact that neither the Air Force personnel nor the RCA per- 
tonnel had previous experience on the RCA 301 dual processor 
configuration. 

Dollars ot Hardware Cost lor Program Checkout (Dev.) 
Proposed: UnkQ 

Actual: 151,780 HHIHBHHi 

Comment : Program and system checkout of PDS required 1,884 hours 
on the RCA 301 configuration. 

llours/Month of Hardware Use for Application Production (Op.) 

Proposed: UnkCZ 

Actual: 

Comment: The actual number reflects the total hours used during 
Marc h 1<H6 for PDS application production on both RCA 301 processors 
at SMAMA. 


Hours/Month of Hardware Use for Program Maintenance (Op.) 

Proposed: Unk l~7 

■■■■■■■■■■I 

Comment : The actual number reflects the total hours used for PDS pro- 
gram maintenance during March 1966 on both RCA 301 processors at 
SMAMA. All PDS program maintenance is done at Hq. AFLC. The opera' 
tional site programmers only collect program error data to send to Hq. 
AFLC and install corrections from Hq. AFLC. 

Number of Operations Personnel (Op.) 

Proposed: 1 1 1 I 

Actual: 10 ■■■■■ 

Comment • The actual number of personnel represents operators at 
SMAMA. The PDS system is not operational at Hq. AFLC. 

Number of Program Maintenance Personnel (Op.) 

Proposed: Unk CZ 

Actual: ■■■■■■■■■■■■ 

Comment : The actual number of personnel is prorated from two 
programmer a at SMAMA on the basis of tirhe spent on PDS program 
maintenance and seven programmers at Hq. AFLC who devote full 
time to PDS program maintenance. 

Dollars/Month of Hardware Cost (Op.) 

Proposed: 17.<H>0 l 1 

Actual: 17,3' 

Comment: None. 


FUTURE PLANS : This system is currently undergoing system design modifications and a com¬ 
plete reprogramming effort in order to incorporate new processing requirements imposed by 
DOD MILSTRAP procedures, to be implemented 1 July 1966. Further into the future, changes 
are anticipated to meet several new DOD MIL systems such as MILSTEP and MILSTAAD. 

The effects of these changes should be considerable although they cannot be fully determined 
at this time. 
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SYSTEM : Major Air Command Personnel Data System-Officers 65--PDSO/MAC (H800/H200) 


DATA SYSTEM DESIGNATOR : E101A, E053, E517 
DATA COLLECTION DATE: April 1966 


Contact for Additional Information 

Headquarters, Air Training Command 
Randolph Air Force Base 

San Antonio, Texas 

Development 

Headquarters, Air Training Command 
Randolph Air Force Base 

Texas 

Maintenance 

Headquarters, Air Training Command 
Randolph Air Force Base 

Texas 

Pilot Installation 

None 

First Operational Installation 

Headquarters, Air Training Command 
Randolph Air Force Base 

Texas 

Number of Operational Installations 

8 


FUNCTION : The users of PDSO/MAC are the Management Information Offices of the major air 
commands and the Consolidated Base Personnel Offices of the various Air Force bases. The 
mission of the users is maintenance of personnel data, assignments, promotions, accessions, 
strengths, and planning. PDSO/MAC functions as a management support system to create, edit, 
control, retrieve, distribute and display active duty officer personnel data. The system inte¬ 
grates personnel information from the base to the major command level and then to USAF head¬ 
quarters level. 


ORGANIZATION: 



(U»er) 
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HISTORY: MAC PDS-O 65 evolved from PDS-O 63. No formal DAP was prepared for MAC 
PDS-O 65, but its development was recognized and authorized as part of the overall vertically 
integrated personnel data system to be developed by the Military Personnel Center (MPC). 

MAC PDS-O 63 programs in COBOL for the Honeywell 800/200 computers were developed by 
the Air Training Command (ATC) at Randolph AFB for the Inquiry System and by HEDCOM at 
Bolling AFB for the Maintenance System. For MAC PDS-O 65, MPC integrated the Major Air 
Command (MAC) data base with the MPC and Consolidated Base Personnel Office (CBPO) data 
bases and completely rewrote the Maintenance System. For the Inquiry System, MPC adapted 
and modified in varying degrees the PDS-O 63 programs. Some of the inquiry programs proved 
to be rather inefficient in COBOL and were reprogrammed by Honeywell in assembly langua^*. 

MAC PDS-O 65 was developed and is maintained by MPC and distributed to the MAC’S for 
implementation. Since the MAC computers (Honeywell 800/200 system) may differ from one 
another in configuration, the personnel at each MAC retrofit the basic MAC PDS-O 65 to their 
own computer. Furthermore, the MAC'S may develop command-unique "add-ons" to their 
PDS-O system. All maintenance and changes in the basic system must be done by MPC. 

Two teams were formed at MPC. One developed the maintenance programs and the other 
developed the inquiry programs. Several of the inquiry programs were adaptations and modifica¬ 
tions of PDS-O 63 programs. The personnel assigned were experienced programmers and per¬ 
formed both the systems analysis and programming function. The computer is in a secured area, 
but this has not been detrimental to implementation or operation. 

Standard Air Force documentation and program reporting procedures were employed 
during development as specified in AFM 171-10. The manual, AFM 30-3, specifying user pro¬ 
cedures, was produced partially by the development effort. 

MAC PDS-O 65 is operational at the following eight MAC Hqs. : SAC, TAC, ADC ATC 
PACAF, USAFSS, USAFE, and HEDCOM. 


SCHEDULE: 
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DESCRIPTION: The system consists of a series of computer programs that create a merged 
manpower-personnel data file, which in turn is used as input to a library of computer sort ap¬ 
plications for production of recurring reports. The sort programs have the ability to be altered 
on a one-time basis in order to provide inquiry of a selected portion of any or all of the recur¬ 
ring reports on an as-required basis. 


t rwn Wait 
•I MAC 



FU. M.N.UMI Suhiyitim 




USA* MAC 

via 

AUTODIN 


In CBPO'a 
AUTODIN 


I" Manaf.manl 

Inlormatinn 

OKU# 
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SOFTWARE : Software for the H800 consisted of a COBOL 61 compiler and an ARGUS assem¬ 
bler. The software was delivered by Honeywell with the equipment in April 1965--2 months 
late. 

Comment : The use of COBOL 61 in the inquiry system proved to be inefficient, resulting in sev¬ 
eral programs being partially rewritten in ARGUS, the assembly and macro language. The 
COBOL 61 compiler also had some bugs which were corrected by Honeywell personnel. 

Honeywell is responsible for the maintenance of the software. 


APPLICATION PROGRAM DEVELOPMENT : The Personnel Data Systems Division of the Mili¬ 
tary Personnel Center was responsible for the development of PDSO/MAC. Twenty experienced 
programmers were assigned the system analysis and programming tasks required for PDSO/ 
MAC development. These personnel were divided into one team responsible for file maintenance 
programs and another team responsible for development of file inquiry programs. 

System design of PDSO/MAC required close coordination with PDSO/MPC and the CBPO 
systems, since these systems are all part of the AF vertically integrated personnel data system. 
All three systems work with the same data elements and thus consistency in format and handling 
had to be maintained across development of these systems. PDSO/MAC system design com¬ 
menced prior to the selection of the H800/200 computer hardware. The system designers had 
assumed a variable word length machine concept which required reorientation on the selection 
of the H800. 

The system was programmed in COBOL 61; however, the inquiry system proved inef¬ 
ficient and parts of several programs were subsequently rewritten in ARGUS assembly language 
by Honeywell personnel. Program and system documentation conformed to standards specified 
in AFM 171-10. PDSO/MAC was given a thorough system test by simulating inputs typical of 
SAC, TAC, and ADC. 


FILE CONVERSION: A separate organizational entity was created to plan the file conversion ac¬ 
tivities. The conversion consisted mainly of changing formats and codes to conform with the 
vertically integrated system. Much interfacing with MPC and CBPO existed. Media included 
both cards and tapes. A team of four was used for 12 months to do the planning, programming, 
and interfacing. Two thorough documents were produced specifying procedures for MAC's and 
CBPO's. These procedures spelled out in detail the flow of information, the changes in codes, 
the media used, the responsible organizations, pre- and post-conversion activities, the timing 
of conversion, and the audits and checks to be applied. In addition, the team oriented MAC and 
CBPO personnel on these procedures through personal visits to the sites. The conversion was 
accomplished very smoothly. The computer time used was not identifiable and is included in 
the checkout hours. 


113 














PDSO/MAC Sheet 6 of 7 


DOCUMENTATION: The system is documented in AFM 30-3 and according to standards specified 
in AFM 171-10. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Yearn 

Sampled 

Allocated to 
System 

In ADP 

In l’ereonnel 
Syatemn 

Of College 

Development 

Manager 

3 

3 

11.0 

7.5 

3.5 

Analyst 

7 

7 

8.0 

14.5 

Unknown 

Prog rammer 

18 

18 

9.5 

4.0 

U nknown 

Ope rations 

Manager 

None 

2 

Unknown 

Unknown 

Unknown 

Operator 

54 

7 

6.0 

2.0 

IxT 


OPERATIONS : All scheduling for the computer operation is automated with monthly and daily 
schedules being updated and generated at fixed intervals by the H800/200 computers. The oper¬ 
ation, a closed shop, is staffed as required by workload. 

Comment : The II800 is currently overloaded at SAAMA. It is planned to augment the present 
computer configuration with another H800. 



6? hr. 9f 


Sc h«l Mt 
59 hr. 8f 
Mach Krror l.o.t 
* hr. If 
Un.cliri Mt 
9 hr. If 


Prod (all app.) 
248 hr. Mf 


Prrp (all appal 
I hra If 


Chg Lo.t (all other app.) 

38 hr. 5f 



Pro# l)rv * Mt (all appa) 

91 hr. I2f 

Ch( l.o.t (all app.) 

4 I hr. hf 


Prod I PDSO/MAC app) 

89 hr. I2f 

Prrp (I'DSO/MAf. *,»>) 

2 hr. If 

ro K Ilrv * Mt (IMl.Sn/MAC app) 
H hra 2 ' 

Pfrvl (all otlii r app.) 

184 hr. 24f 


Prep (all other app.) 

1 hr If 

/ 'Pro# Dev ♦ Mt (all other app.) 
HI. hr. in 


1-liK I ><*.t (PDSO/MA( 
9 hr. If 


«PP) 


APPLICATION PH OCR AM MAINTENANCE: All program maintenance of the basic PDSO system 
is doncT by the Pe rsonne 1 Data Systems Division at the Military Personnel Center. However, 
since the MAC computers (H800/200 system) may differ from one another in configuration, the 
personnel at each MAC retrofit the basic PDSO system to their own computer configuration. 
Furthermore, the MAG's may develop command-unique "add-ons" for their installation. All 
development programmers and analysts were phased into program maintenance. Maintenance 
consists of 60 percent program improvements and 40 percent corrections. Programmers re¬ 
ceive from one checkout run per day to two or three per week. Dolling AFD is often used for 
program testing because of its light computer load. 

Comment: None. 
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BENEFITS ; Proposed ; PDSO/MAC was proposed to be the major air command element of a 
three-level, vertically integrated personnel data system for officers. Specific benefits that 
PDSO/MAC was to provide include increased responsiveness to commanders and management 
in the creation, edit, control, retrieval, distribution, and display of active duty officer person¬ 
nel data. Other benefits were to be the standardization of personnel systems across all major 
air commands and significant cost reduction in personnel data handling. 

Actual; PDSO/MAC has provided increased responsiveness to commanders and management 
In the creation, edit, control, retrieval, distribution, and display of personnel data. Person¬ 
nel systems were standardized across major air commands and standard data elements were 
adopted throughout the vertically integrated system. 


COST FACTORS; 


Man-Montha of Davclopmant Effort (Dev.) 

Proposed Unk CZ 

Actual: 489 

Comment : No formal DAP wai praparad for PDSO/MAC. Its developmant 
wai recognised aa a part of the overall vertically* Integrated PDSO. 

Montha of Elapsed Development Time (Dev.) 

Propoaed: link CZ 

Actual: 22 

Comment : PDSO/MAC eystem design commenced in March 1964. The 
ayatem waa declared operational at ATC on 1 December 1965. 

Dollars of Hardware Coat for Program Checkout <Dev.) 

Propoaed' Unk CZ 

Actual: 84,700 

Comme nt : 1, 300 houra war* uaed for program c heckout. The number of hour a 
include a an unknown number of hour a required for file conver a Ion. Approxi¬ 
mately 100 of the 1,300 hour s were uaed at iocatlona other than ATC'a H800. 

Hours/Month of Hardware Uae for Application Production (Op.) 

Propoaed: Unk CZ 

Actual: 89 ■■■HH 

Comment : The actual number reflecta uaage during March 1966 on the 
Honeywell 800 computer. PDSO/MAC application production uaage la 
not known for the Honeywell 200 computer 


Houra/Month of Hardware Uae for Program Maintenance (Op.) 

Propoaed: Unk CZ 

Actual: 14 

Comment : The actual number reflecta uaage during March 1966 on the 
Honeywell 800 computer. PDSO/MAC program maintenance uaage la not 
known for the Honeywell 200 computer. 

Number of Operatlona Peraonnel (Op.) 

Propoaed: Unk CZ 

Actual: 7 

Comment : The actual number of peraonnel la prorated from 21 operator a 
allocating approximately 30 percent of their time to PDSO/MAC, 

Number of Program Maintenance Peraonnel (Op.) 

Propoaed: Unk CZ 

Actual: 9 

Comment : The actual number of peraonnel repreaents original 
development peraonnel. 

Dollara/Month of Hardware Coat (Op.) 

Propoaed: Unk CZ 

Actual: 10,457 

Comment: None. 


FUTURE PLANS ; The current machine configuration is overloaded and does not supply the Mili¬ 
tary Personnel Center adequate checkout time for its function as centralized development and 
maintenance organization for PDS-O 65. It is planned to augment the present configuration with 
another H800. Sufficient H200 capacity is available to serve both processors. 
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SYSTEM : Personnel Data System-Officers, Military Personnel Center--PDSO/MPC 
(Burroughs 5500) 


DATA SYSTEM DESIGNATOR: E053 and El01A 


DATA COLLECTION DATE: March 1966 


Contact for Additional Information 

Air Force Military Personnel Center 
Randolph Air Force Base 

San Antonio, Texas 

Development 

Air Force Military Personnel Center 
Randolph Air Force Base 

Texas 

Maintenance 

Air Force Military Personnel Center 
Randolph Air Force Base 

Texas 

Pilot Installation 

None 

First Operational Installation 

Air Force Military Personnel Center 
Randolph Air Force Base 

Texas 

Number of Operational Installations 

1 


FUNCTION : The users of PDSO/MPC are the Directorates of Personnel Services, Personnel Re¬ 
sources and Distribution, and Personnel Program Action, USAF Military Personnel Center. A 
commonmission of the users is the maintenance of personnel data such as assignments, accessions, 
separations, promotions, and integrations. PDSO/MPC functions as a management support system 
to maintain a central file of personnel data on all active Air Force officers. Other important func¬ 
tions of the system include maintaining manning data on Air Force organizations by grade and func¬ 
tional category, and Personnel Accounting Symbols for all Air Force units. An on-line inquiry ca¬ 
pability enables the Military Personnel Center staff to have access to certain data within 90 seconds. 

ORGANIZATION: 
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HISTORY : PDSO-65 evolved from PDSO-63, an automated personnel system operated at Head¬ 
quarters, USAF. A need to integrate the personnel data systems vertically at Headquarters, 
USAF, the major air commands (MAC's) and consolidated base personnel offices (CBPO's) gave 
impetus to the development of the system. In addition, a direct inquiry capability was to be in¬ 
cluded in the new system. The hardware configuration was selected by the EDP Equipment Of¬ 
fice (ESQ). All development work was done at the USAF Military Personnel Center (MPC). 

A planning group of personnel from all major users of the system and other related sys¬ 
tems was established to outline the areas of PDSO-63 requiring redesign. The development was 
broken down into two primary areas: (1) design and documentation of specifications, and (2) 
programming and system implementation. Both of these major areas were broken down into 
tasks and the responsibility for these tasks was delegated. Standards for programming, docu¬ 
mentation, and management control were also specified. 

The Directorate of Personnel Systems had overall responsibility for the redesign of 
PDSO-63 and the implementation of PDSO-65 at the Military Personnel Center. The entire per¬ 
sonnel resources of the CBPO Division, MAC Division, MPC Division, and the Plans and Ad¬ 
ministration Office were assigned to the effort. In addition, partial support was supplied by 
the Systems Development Division. Limited resources were available in other directorates of 
the USAF Military Personnel Center and directorates of Headquarters, USAF. 

An extensive set of documents exist describing the system objectives, processing, and 
data element formats. The documentation is oriented toward the total vertical personnel sys¬ 
tem, since users (suppliers of input to PDSO/MPC) will be lower level subsystems in the ver¬ 
tical structure. 


SCHEDULE: 


CY 1965 


! CY 1966 


CY 1968 


jj|asondj aim j[j|a[s oInId jIfIma m j jL s ondjfmamj jasond 


J FMAMJJASONDJFMAMJ JASOND 


APDSA System Specification* Written 
II 


O Planned Date 


▲ Actual Date 


Hardware Specification* for PDSA/PDSO Written 
m Hardware Propoaal Evaluation | J 
A PDSO-65 Impiemented on IBM 7080/1401 at Pentagon 
A B5000 Award Announced | | j | | J | | J 

APDSA Dropped for B5000 Became PDSO-63 Could Not Be Converted Directly 
I 1 [a PDSO-65 Sy*tem Specification Written 


* 


jin. 

A Programming and Checkout 
0 'Delivered j J I 

A B5500 Accepted 

.. • 

System Te*t 

Conversion 


Development Stage 

I.1.I-I.IU.L 


5? P V* ti0n * 1 < si| pp»«® Because of Late Delivery of 
n800/i00'a for MAC s) 

■I.UJ-U 


Operational Stage 

lllllllll 
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DATA BASE 

Char, in Data Baae: 

276.700,000 

Percent of Char, on D/A Storage: 

86 

Mlllieeconda of Acceaa Time for D/A: 

20 

No. of Data Baae Record Typea: 

6 

No. of Data Baae Recorde: 

544,500 

Percent Growth Rate /Mo. x 

1.1 

Char. /Mo. of Update Input: 

45,850,000 


WORKLOAD: 


PROCESSING 

FUNCTIONS 


Char. /Mo. of Input 


Volume: 

46.460.000 

No. of Input Traae- 


action Typea: 

122 

No. of Input 


Data Fielda: 

681 

Percent of Input 


Rejecta: 

4.3 


Key 

100% 

90 

SO 

70 S 
60 § 

SO 
40 

30 ^ 

20 
10 
0% 


•» _ C 

Is cl 


t 

<s 


i t 
I id 
3 23 


t 


nil 


■iA -li 


Ihn 


Total Source Inatructione: 
Total Object Instnactione: 
Hra. /Mo. of Application 
Production: 


Baae Compute r( a) 

195.100 

780.S00 


Peripheral 
Compute r( a) 

NA 

NA 


Char. /Mo. of Out* 


put Volume: 

81,600,000 

No. of Output 


Formate: 

141 

Reaponae Time 


(aeconda): 

90.0 


HARDWARE: 


B4M 

Remote 

Inquiry 



Com¬ 

puter 

Firat 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(u») 

Internal Storage 

External Storage 

Peripheral Devicea 

Mag Tapea 

Diak 

Ci 

ird Read 

er/Punch 

Printer 

Remote Coneolea 

No. 

Mag 

Tapea 

Tran a. 
Rate 

No. 
Diak a 

Trane. 
Rate 
(char. / 
aec) 

Char. 

Ca¬ 

pacity 

Ac- 

ceaa 

Time 

(me) 

No. 

Read 
Speed 
(carda/ 
min) 

No. 

Punch 

Speed 

(carda/ 

min) 

No. 

Speed 

(Ipml 

No. 

Speed 

(char./ 

•ec) 

Cycle 

Time 

(ue) 

Word 

Siae 

(bita) 

Word 

Ca¬ 

pacity 

B5500 

11/64 

Word 

2 

4 

48 

32.768 

8 - 

B422 

24K to 
66K 

25- 

B475 

100K 

9.6M 

20 

1* 

Bl 24 

800 

1- 

B304 

300 

1- 

321 

650 

14- 

B49J 

10 


U9 
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SOFTWARE : Software for the Burroughs 5500 consisted of COBOL and ALGOL compilers, an 
ESPOL assembler, hardware diagnostic, debugging aids, and a Master Control Program (MCP), 
No utility routines were supplied by Burroughs, but some were obtained from the Burroughs 
user group. The software was delivered by Burroughs with the equipment in February 1965. 

Comment : The initial COBOL compiler lacked many desired features (e. g. , disk constructs, 
sort and merge verbs). A COBOL compiler with the disk constructs, the sort verb, and merge 
verb (which still gives problems) was delivered in May, 1965. Program checkout with COBOL 
was difficult because of no run time patching or modification capability and the absence of an 
intermediate or assembly language output to aid in the analysis of programs. The programmers 
also felt that more extensive diagnostic messages from the COBOL compiler would have assisted 
program development. ALGOL diagnostics were felt to be adequate. The compilers and assem¬ 
bler were on the whole highly successful and contributed to system development. 

MCP was converted to operate with the disk construct in May, 1965. The users feel that 
checkpoint and restart capability should be on a controlled basis rather than periodic. The pri¬ 
mary attribute of MCP that assists effective operation is the automatic scheduling of jobs and 
I/O assignments, which achieves efficient peripheral device utilization. The rigid structure of 
MCP does not allow easy modification for handling nonstandard formats, such as tapes of differ¬ 
ent labeling format. MCP is used to maintain the application program library and to call all 
functional programs from this library. 

It was felt that the channels for dissemination of information on the software and correc¬ 
tion of errors were generally not responsive to the requirements of the system users. The 
program documentation was usually delivered much later than the software itself and was some¬ 
times inconsistent with the software. 

Representatives of the manufacturer are maintained on site to assist with any problems 
in the support software. In addition, several AF personnel have been trained in the maintenance 
of the operating system and compilers. The systems programming people are also involved in 
making recommendations for modifications to improve the efficiency of the system operation. 

APPLICATION PROGRAM DEVELOPMENT : A planning group of personnel from all major users 
of the PDSO-63 system outlined the redesign of PDSO-63. The same group also provided the 
design specification documentation, programming standards and system implementation of 
PDSO-65. The programming effort was divided into two areas: (1) file maintenance, and (2) file 
retrieval. There are 74 distinct file maintenance programs, which were written in COBOL. 
There are 80 file retrieval programs written in COBOL in addition to the on-line retrieval pro¬ 
grams, which were written in ALGOL for efficiency of operation. Each program was checked 
out individually prior to the systems test. No program patching capability was available. This 
caused an inordinate amount of checkout time to be used for recompilation. The complete sys¬ 
tem test, designed to fully exercise the assignments, promotions, separations and integration 
of subsystems, was planned and completed on schedule. 


FILE CONVERSION: The file conversion activity was documented and was planned for execution 
between 6 and 12 October 1965. A flow chart was drawn; all master files and intermediate work 
files of the PDSO system were specified and file formats and record contents indicated. 

While 7080/1401 tapes were compatible with B5500 tapes, COBOL (135500) would only 
process Burroughs tandard labels, and consequently tape labels on original tapes had to be mod¬ 
ified accordingly before conversion. Necessary programs were prepared. A total of 29 files 
were converted. These were systematically analyzed and the volume indicated by the number 
of reels, records, blocks per record, and characters per block for each file. 

Computer time used: approximately 60 hours. 
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DOCUMENTATION : User documentation is aimed at those who supply input at the lower level in 
the vertical structure. Other documentation includes system design review notes, program 
changes, etc. A folder is maintained for each program containing listings, flow charts, and 
program specifications. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
System 

In ADP 

In Personnel 
Systems 

Of College 

Development 

Manager 

15 

15 

8.5 

7.0 

3.5 

Analyst 

7 

7 

4 

11.5 

U nknown 

Programmer 

37 

40 

7.0 

5.5 

Unknown 

Operation* 

Manager 

3 

3 

12.0 

2.5 

2.0 

Operator 

29 

52 

4.5 

0.5 

X 


OPERATIONS : The computer operation is staffed 24 hours a day, 7 days a week. It operates as 
a closed shop. PDSO/MPC is the only application on the Burroughs 5500 computer. Immediate 
queries are processed on-line during normal working hours 5 days per week in a multiprogram¬ 
ming mode with scheduled runs. Deferred inquiries and file maintenance are run at other times 
according to a master schedule. 

Comment : Program development and maintenance time is somewhat large due to lack of pro¬ 
gram patching capabilities. A large percentage (21 percent) of time is taken for computer 
maintenance and machine error lost time, reflecting low hardware reliability. 


Other 
27 hrs 4 f 
Off 

23 hrs 3$ 
Schd Mt 
79 hrs lift 

Mach Error Lost 
45 hrs 6$ 


Prep 
14 hrs 2% 


APPLICATION PROGRAM MAINTENANCE : There are currently 36 programmers and 14 system 
analysts involved in program maintenance for PDSO/MPC, all of whom were involved in the de¬ 
velopment efforts. The program maintenance activity is divided among corrections to programs, 
system documentation, system improvements, and program operational efficiency improvements. 

Comment : The large amount of time devoted to the program maintenance effort is mainly due to 
the fact that a completely new system has not been operational very long and problems are still 
being encountered in the software. 


Unschd Mt 
29 hrs 4$ 
Idle, 

. 27 hrs 4% 

Set Up, 
22 hrs 3% 
Chg Lost 
20 hrs 3% 
Prog Dev & Mt 
68 hrs 9% 



Burroughs 5500 



Prod (PDSO MPC 
only app) 376 hrs 51% 
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BENEFITS ; Proposed : The PDSO/MPC was established along with the USAF Military Person- 
neTCenter by direction of the Secretary of the Air Force. Prior to PDSO/MPC, Air Force Hq. 
personnel processing was performed on an IBM 7080 at the Pentagon. The PDSO/MPC system 
was to provide a number of new benefits, including (1) inclusion of significant additional data 
on each Air Force officer; (2) standardization of data codes and formats to enhance efficient 
communications of personnel data from one AF personnel system to another; and (3) immediate 
access to personnel data for personnel managers. 

Actual: PDSO/MPC became operational in October 1965. It provided the additional officer data 
and standardization of data codes that was required. Communications with other AF personnel 
systems were enhanced, since PDSO/MPC was designed as the top component of a three-le\ol, 
vertically integrated personnel system. Remote immediate access terminals were provided. 
However, due to the saturated computer utilization, updates could be run only three times weekly 
(compared with a proposed daily update), thereby causing personnel data to be less current than 
originally proposed. This problem is presently being alleviated by procurement of additional 
hardware modules for the system. 


COST FACTORS: 


Man-Months of Development Effort (Dev,) 

Proposed: Unk CZ 

Actual: 1,443 MBM 

Comment ; No formal DAP was prepared for PDSO/MPC. An advanced 
design team bogan work in May 1963 to eatabliah objectivea and equip- 
ment requirements for PDSO 65. This effort evolved Into the PDSO 65 
Bystem design begun in April 1964. 

Montha of Elapsed Development Time (Dev.) 

Proposed 16 1 1 

Actual: 2( 

Comment : A proposed date for PDSO 65 implementation waa eatabliahed 
ty the PDSO 65 design team aa July 1965. Because of late delivery of the 
MAC Honeywell 800/200 computers, the implementation of PDSO 65 waa 
delayed until November 1965. 

Dollars of Hardware Coat for Program Checkout (Dev.) 

Proposed: UnkCZ 

Actual: Unk K 

Comment : Computer tune used before the acceptance of the computer on 
T M*v I /05 was no* logged. After acceptance, it la known that at least 
1,112 hours were used for program checkout between May and September 
1965, coating approximately $266,880. Program checkout waa lengthened 
because of the excessive recompilation required due to inadequate 
program-patching capabilities with COBOL. 

Houra/Month of Hardware Use for Application Production (Op.) 

Proposed; Unk CZ 

Actual: 37' ■■■■■■■■■■■ 

Comment: Peflecta usage during February 1966 on the Burrougha B5500 
computer. 


FUTURE PLANS : Excessive workload on PDSO/MPC has resulted in degradation of system per- 
formance (master files are only updated three times weekly as opposed to a planned daily update). 
Proposed improvements in the hardware configuration to handle the workload include; (1) in¬ 
crease the number of modules from six to eight and increase memory speed from 6 \is to 4 ps; 

(2) add another central processing unit; (3) increase the number of tape drives from 8 to 14; .and 
(4) increase the number of disk storage modules from 25 to 32, giving 307.2 million characters 
of disk storage instead of 240 million. At this time, there are no major design changes contem¬ 
plated for PDSO/MPC system programs. 


Houra/Month of Hardware Use for Program Maintenance (Op.) 

Proposed: Unk CZ 

Actual: 68 

Comment : Reflects usage during February 1966 on the Burrougha B5500 

computer. 

Number of Operations Personnel (Op.) 

Proposed: UnkGL 

Actual: 5< 

Comment : The actual number of personnel represents operators at the 

Military Personnel Center. 

Number of Program Maintenance Personnel (Op.) 

Proposed: UnkCZ 

Actual: 50 

Comment : The actual number of personnel consists of 14 analysts and 
programmers. 

D ollar s/Month of Hardware Cost (Op.) 

Proposed: Unk C2 

Actual: 64.78(1 

Comment: None. 
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SYSTEM : Regional Accounting and Finance Test--RAFT (RCA 301) 


DATA SYSTEM DESIGNATOR : H060 
DATA COLLECTION DATE: April 1966 


Contact for Additional Information 

ATAAF Accounting and Finance Dir. 
ATADC-DCS/Comptroller 

Randolph Air Force Base 

San Antonio, Texas 

Development 

Randolph Air Force Base, Texas 

Sheppard Air Force Base, Texas 

Maintenance 

Sheppard Air Force Base 

Texas 

Pilot Installation^ 

Sheppard Air Force Base 

Texas 

First Operational Installation^ 

Sheppard Air Force Base 

Texas 

Number of Operational Installations 

1 


Note: (1) Entire system was a pilot system deactivated in June 1965. 


FUNCTION : The users of RAFT are the Base Accounting and Finance Offices at Sheppard, 
Reese, Vance, and Webb Air Force Bases. The mission of the users is to perform the ac¬ 
counting and finance functions for their respective bases. RAFT functions as a research and 
development support system in that it is the result of a pilot project to design, develop, and 
test a standard USAF base level regional accounting and finance system (excluding military 
pay), utilizing electronic data processing equipment. RAFT was deactivated in June 1965. 


ORGANIZATION: 



Function*! Responsibility 
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HISTORY : The Air Training Command (ATC) was requested by Headquarters USAF to investi¬ 
gate the development of a small regional accounting and finance system. An ATC planning 
group was formed that developed general project concepts and an agenda for a meeting with 
representatives of Headquarters USAF. This meeting was held in March 1962 and an action 
schedule was developed encompassing the concept preparation, system design, programming, 
testing, and evaluation. Development took place at Randolph AFB. RAFT became operational 
at Sheppard AFB in December 1963 and later at Reese AFB, Vance AFB, and Webb AFB. 

The system was designed as a test, and the test was successfully completed. RAFT was de¬ 
activated in June 1965 due to loss of computer support. 

Data systems analysts assigned to the project had extensive background and training in a* - 
counting and finance, whereas their training in system design with EDP equipment was not as 
extensive. Data systems programmers assigned to the project had no previous programming 
experience or instruction in programming and were sent to RCA 301 programming school. 

The team concept was employed in development, with a team consisting of a functional expert 
in the accounting and finance area, an analyst, and a programmer. Critical path scheduling 
and progress reporting techniques were used throughout the development of RAFT. 


SCHEDULE: 


j"jr mIaIJTjIa s|on i) 


.1 h |M] XC l J J A ‘‘ O N I) J F M A M J J A S ON D 


JKMAMJ J A S O N P J h M A 


M A M J J A S O Nil) 


rmitir 

A Actual Date 


HQ USAF Soltiited ATC Interest in Reft 

111.. i I I | I It II 

4 ATC Accepted end Formed Planning Grou 

A Pilot Project Authorised I I I I 
± l I » l t t l i • I I II 
— kP lan and Concept* Prepared | 


O Planned Dale 


| ■ | ■ | ■ j 1 | j ^ System Design 
A Systems and Programming Cl. 


Proposal Stage 

1.1.1.1.1.1 I. 


„ M II I I 

Programming 


i i < i i 


Ajest and Debug at HEW, Wash. 

A^RCA 301 Installed at Sheppard AFR 

Test and Debug at Sheppard 


Development Stage 

I I II I I I I I 



4<j) F.v.lu.jlo,, | | I I I 

Sheppard Operational j 
J r “ ^ k J Other Sites C 


Operation* 


Operational Stage 

I I I I I I I I 


4 Rtlt Deaitivaied 
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DESCRIPTION: The RAFT system functions are Civilian Payroll, Travel and Transportation 
(processing of open accounts on individual travelers), Commercial Services (processing of 
procurement functions), Reimbursements (maintenance of customer accounts), and Accounts 
Control (update of commitment and obligation, MAFR, check payment, and accountability 
records). Financial input information is sent to the regional office (Sheppard AFB), and the 
accounting and finance offices of the four bases (the users) receive in return products for base 
and employee use. These include payroll vouchers, payroll checks and bonds, printouts of 
status of open accounts, and various budget reports. 






R.c.lv.4 From 
Bt.« vt. AUTODIN 
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DATA BASE 

Char. In Data Base: 

17,510.000 

Percent of Char, on D/A Storage 

NA 

Milliseconds of Access Time for D/A: 

NA 

No. of Data Base Record Types: 

• 

No. of Data Base Records: 

135,500 

Percent Growth Rate/Mo. : 

Unk 

Char. /Mo. of Update Input: 

6.402.000 


WORKLOAD: 


PROCESSING 

FUNCTIONS 


Char./Mo. of Input 


Volume: 

6,402,000 

No. of Input Trans¬ 


action Types: 

48 

No. of Input 


Data Fields: 

227 

Percent of Input 


Rejects: 

0.8 


Key 




t 

s 


5 2 

o. c t 

t? O O 


100 % 

90 

80 

70 

60 

50 

40 

30 

20 

10 

0% 


Total Source lnetructlona. 
Total Object Inatructions: 
Mrs,/Mo. of Application 
Production. 


OUTPUTS 


Hi „ Jr 

i it 

A 

■Si M ■ 


lLh 


Rase Computer(») 

34.620 

34.620 


Peripheral 
Compute r(e) 

NA 

NA 


Char. /Mo. of Out* 
put Volume: 26,070,000 

No. of Output 
Formate: 57 

Reaponee Tima 
(aeconde): NA 


HARDWARE: 


Console 


RCA 304 


IBM 1402 

Central 


Card 

Processing 


Reader/ 

Unit 


Punch 


RCA 316-1 
■ Printer 


RCA 333 

Control 


Printer 


RCA 318 

Hi-Data 

Control 


RCA 319 

Hi-Data 

Control 



RCA 301 


Com¬ 

puter 

First 

Deliv¬ 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Internal Storage 

External 

Storage 

Peripheral Devices 

Card Reader/Punch 

Printer 

Add 

Time 

(us) 

Cycle 

Time 

(us) 

Char. 

Size 

(bits) 

Char. 

Ca¬ 

pacity 

No. 

Mag. 

Tapes 

T rans. 
Rate 

No. 

Read 
Speed 
(cards/ 
min) 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

(ipm) 

RCA 

301 

2/61 

Char. 

98 

7 

6 

20K 

6- 

38lU> 

10K to 
66K 

1- 

1402 

800 

250 

1- 

333 

L000 


Comment: (1) Housed in one cabinet. 
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SOFTWARE : Software for the RCA 301 consisted of the following: (1) a symbolic assembly 
language assembler; (2) a Utility Service Reference; (3) a '’consolidate, 1 ' (4) a Test Library 
Tape (TLT) and Program Library Tape (PLT); and (5) a sort program. The software was 
delivered by RCA with the equipment in June 1963. 

Comment: "Consolidate" provides for selective dynamic memory dumps and traces. A routine 
was added by the Chief Programmer on the RAFT project to TLT and PLT to provide for run-to- 
run operating instructions. There have been no formal system programming activities. An 
RCA system representative provided software support. 


APPLICATION PROGRAM DEVELOPMENT : The responsibility of RAFT was balanced between 
two USAF elements of the Accounting and Finance Directorate and the Data Automation 
Directorate. The former established policy and described output demands on the system. The 
latter designed and developed the ADP system. The system design phase included detailed 
flow charts, input/output requirements, stored data requirements, and transaction codes to be 
used in operations. The programs were written in COBOL by programmers trained at the 
RCA 301 programming school. Due to the 300-mile distance between the programming loca¬ 
tion and the checkout computer, the checkout was not begun until programming was virtually 
completed. RCA provided 90 hours of free test time during the 461-hour checkout, the amount 
of checkout time was high due to machine and tape malfunctions. Special input data was de¬ 
veloped for program checkout. Computer time was supplied by open shop operations with pro¬ 
grammers getting as many as five runs per day. System tests also consisted of parallel oper¬ 
ations after completion of all program testing and debugging. Critical path scheduling using 
LESS (Least Cost Estimating and Scheduling) and weekly progress reporting using PROMT 
(Planning and Progress Measurement Techniques) were the management control methods used. 


FILE CONVERSION: Conversion procedures to be used by the bases in converting their man- 
ual records to RAFT input formats were developed by RAFT project personnel within the 
applicable subject matter areas. During the conversion period, RAFT project and accounting 
and finance personnel visited each base and were on hand to assist them with any problems en¬ 
countered in converting their records. The conversion was from manual records to punched 
cards. The punch card information was sent to the region via AUTODIN and received at the 
regional office in the form of punched cards. No major problems were encountered in base 
conversions. A problem did arise when it was discovered that the AUTODIN equipment at 
the bases could not send or receive credit zeros. This problem was eliminated by equipment 
modification. Each base was converted by functional area which reduced confusion and per¬ 
mitted an orderly flow of data into the region office. This gave region office personnel ade¬ 
quate time to load and audit the input data. No special programming was required. 
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DOCUMENTATION : User documents as well as system design specifications were produced by 
the system designers during the system design phase. Flow charts were produced prior to 
coding. All deviations from these flow charts are documented on program change forms during 
the coding, check, and maintenance phases. AFL 177-3, Terminal Documentation Parti con¬ 
tains the General Systems Specifications and Part II contains the Evaluation Schedules. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
Syatem 

In ADP 

In Accounting 

Of College 

Development 

Manager 

3 

3 

1.0 

11.0 

3.0 

Analyst 

7 

7 

2.0 

7.0 

Unknown 

Programmer 

14 

14 

1.5 

0 

Unknown 

Operation! 

Manager 

1 

0.6 

9.0 

0 

3.0 

Operator 

4 

2.4 

5.0 

0 



OPERATIONS : RAFT was run during the second shift at Sheppard AFB on an RCA 301. It was a 
closed shop operation. Since the RAFT system is no longer operational, current computer utili¬ 
zation figures do not exist. The figures in the pie chart are averages of utilization d uring 
RAFT's operational phase. 

Comment : The "Other Time" could not be broken down for the only other application, the Base 
Supply System. 



RCA 301 


Prod (RAFT app) 
126 hrs 17$ 


Other 

604 hrs 83$ 


APPLICATION PROGRAM MAINTENANCE : There were three programmers involved with 
program maintenance. Their main function was to correct program errors and to link the 
various programs together into a smooth operating system. The ratio of program corrections 
to program improvements was 9 to 1. The programmers generally received two test runs 
per day during RAFT's operational phase. 

Comment: The maintenance programmers also performed machine scheduling, production 
control, and maintenance of the tape library of 400 tapes. 
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BENEFITS: Proposed: RAFT was proposed as a pilot project to verify the regional accounting 
concept. A major air command accounting concept had been rejected by Hq. USAF, and RAFT 
was designed to determine the feasibility of a centralized system over a smaller number of bases. 
Benefits sought in RAFT included improved product design, elimination of unnessary items and 
reports, greater accuracy, and improved internal and external control. 

Actual: RAFT became operational at four AF bases in June 1964, thus verifying that a region¬ 
alized accounting and finance system was feasible. Because of hardware availability problems 
and plans for an Air Force-wide standard accounting and finance system, RAFT was discon¬ 
tinued. Concepts developed in RAFT will be used in development of subsequent accounting 
finance systems. 


COST FACTORS: 


Man-Month* of Development Effort (Dev.) 

Proposed: Unk CZZ 

Actual: 381 

Comment : No formal DAP was prepared for RAFT. At a meeting 
between Ilq. USAF peraonnel and ATC persdnnel, Air Force letter 
177-3 was drafted containing RAFT concepts and schedules. 

Months of Elapsed Development Time (Dev.) 

Proposed 18 1 1 

Actual: 21 

Comment : RAFT system design began on schedule on 1 June 1962. 
RAFT programming also began on schedule on 1 July 1962. Both 
activities ended on schedule. The schedule slippage was due to a 
delayed start of program checkout, caused by a delay In the installa¬ 
tion of the RCA 301 at Sheppard AFB, until 26 June 1963. Serious 
mechanical problems in the tape units hindered checkout from July 
to late October 1963. when they were overhauled. 

Dollars of Hardware Cost for Program Checkout (Dev.) 
Proposed: Unk CZ 

Actual: 29.97C 

Comment : It was felt by the developers that program checkout hours 
would have been less If,the equipment had been more reliable. Program 
checkout required 461 hours on the RCA 301 computer. 

Hours/Month of Hardware Use for Application Production (Op.) 

Proposed: UnkC2 

Actual: 126BHBMHHIHH 

Comment : The actual number represents the average monthly applica¬ 
tion production usage during RAFT's 18-month operational phase 
(January 1964 to June 1965) at Sheppard AFB. RAFT was usually run 
second shift after all other work on the Base Supply System had been 
completed. 


FUTURE PLANS : The region concept of base level accounting and finance was acceptably 
demonstrated by conducting a comprehensive test of the RAFT system. RAFT was deactivated 
in June 1965 upon completion of this test. This action was taken primarily because the RCA 
301, which RAFT operated on, was replaced by the UNIVAC 1050 II in accordance with stand¬ 
ardization of the Air Force's automated inventory control system at a base level. The major¬ 
ity of the accounting and finance functions that were performed by RAFT have been adapted 
to a card system on a Burroughs B263 at base level. A new accounting and finance system is 
currently in development using some of the concepts that were developed and tested in RAFT. 
There is some discussion that this new system should be usable either at one base or at sev¬ 
eral bases at a central location. The workload analyses for this new system were developed 
by RAFT personnel. 


Hours/Month of Hardware Use for Program Maintenance jQp.) 

Proposed: Unk f~~7 

Actual: Unk K 

Comment : Since RAFT was deactivated in June 1965, current monthly 
uaage figure* do not exist. The program maintenance average monthly 
usage during the 18-month operational phase Is unknown. 

Number of Operations Personnel (Op.) 

Proposed: Unk CZ 

Actual: 3 

Comment : The actual number of personnel was prorated from four oper- 
ators and one EDP officer on the basis of time spent on RAFT during the 
18-month operational phase at Sheppard AFB ending in June 1965. 

Number of Program Maintenance peraonnel (Op.) 

Proposed: Unk CZ 

Actual 4 

Comment : The actual number of peraonnel wa# prorated from two analysts 
and four programmers on the basis of time devoted to RAFT program 
maintenance during the 18-month operational phase at Sheppard AFB ending 
In June 1965. 

Dollars/Month of Hardware Cost (Op.) 

Proposed: Unk CZ 

Actual: 8,775 

Comment : The actual dollar amount Is based on regular shift changes 
However, the RAFT project allocated hardware costs on the basis of extra 
shift costs for those components that were shared with other applications, 
since RAFT used only second and third shift time. The cost of the six 
tape units used only by RAFT was borne completely by RAFT. 
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SYSTEM : Repair Requirement Computation--RRC (IBM 7080/1401) 


DATA SYSTEM DESIGNATOR: D07 3 


DATA COLLECTION DATE: July 1966 


LOCATION: 


Contact for Additional Information 

SACS San Antonio Air Materiel Area 

Kelly Air Force Base 

San Antonio, Texas 

Comptroller (Data Management Division) 
Hq. , Air Force Logistics Command 
Wright-Patterson Air Force Base 

Dayton, Ohio 

Development 

Hq. , Air Force Logistics Command 

Wright*Patterson Air Force Base 

Ohio 

San Antonio Air Materiel Area 

Kelly Air Force Base 

Texas 

Warner-Robins Air Materiel Area 

Robins Air Force Base 

Georgia 

Maintenance 

Hq. , Air Force Logistics Command 
Wright-Patterson Air Force Base 

Ohio 

Pilot Installation 

San Antonio Air Materiel Area 

Kelly Air Force Base 

Texas 

Oklahoma City Air Materiel Area 

Tinker Air Force Base 

Oklahoma 

First Operational Installation 

San Antonio Air Materiel Area 

Kelly Air Force Base 

Texas 

Number of Ope rational Installations 

7 


FUNCTION : The users of RRC are the Directors of the Material Maintenance Divisions of the 
various AFLC Air Materiel Areas. The mission of the users is the management of the repair 
activity of Air Force materials. RRC functions as a management support system to identify the 
items, quantities, and urgency of need of those items to be repaired by the Specialized Repair 
Activity (3RA). The system functions on a biweekly frequency and produces a time phase state¬ 
ment of repair requirements in order of precedence and preference, to be accomplished by 
the SR A. 


ORGANIZATION: 



(Developers/ 
Maintalnrr*) 


(Operator*) 
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HIS TOR Y : Investigations by various government agencies in 1964 uncovered two major prob¬ 
lems in operations of the Air Force Logistics Command (AFLC). First, an ineffective inven¬ 
tory system existed, permitting one agency within the command to purchase items that were 
being discarded simultaneously by another agency within the command. Second, an inadequate 
repair system existed, resulting in some aircraft being inoperative for many months awaiting 
maintenance for lack of proper scheduling of parts, manpower, and facilities. 

As a result of these findings, the Commander, Headquarters AFLC, ordered a review of 
the management of recoverable (repairable) items. This review concluded that AFLC did not 
have the managerial tools to fulfill this function effectively. Large-scale data processing sys¬ 
tems were being planned for the distant future to solve this problem, but it was imperative 
that an interim solution be developed. 

A six-man study group was formed from managerial level personnel of the Data Management 
Division of Headquarters AFLC. This group concluded that an automated system should be de¬ 
veloped to permit the identification of items and quantities needing repair and to react in a 
short-range time period more closely aligned to the actual demand on AFLC. This group 
formed the nucleus of a special developmental task force that drew up specifications for the 
proposed system in March 1965. The programming effort began in April 1965 at Warner- 
Robbins Air Force Base as IBM 7080 computer time was available there. The Management 
of Items Subject to Repair (MISTR) system resulted from this effort. The Repair Requirement 
Computation System (RRC) is the portion of the MISTR system that computes the repair re¬ 
quirements for inventory maintenance. 

System tests began in May 1965 at Warner-Robbins AMA and San Antonio AMA. Implemen¬ 
tation began at all AMA's in June 1966. During system implementation, approximately 70 
major problems requiring changes to the MISTR system were cataloged. The task group di¬ 
rected the extensive modifications to the system and completed their task in June 1966. 

No special management techniques were used to control the development of the system. 
Progress reports on the development status were submitted to Headquarters AFLC on a 
monthly basis. 

RRC is operational at the following seven sites: Rome AMA, Sacramento AMA, San 
Bernardino AMA, San Antonio AMA, Oklahoma City AMA, Ogden AMA, and Warner Robbins 
AMA. 


SCHEDULE: 
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DESCRIPTION: The Repair Requirement Computation System identifies the items, quantities 

and urgency of items to be repaired by the Specialized Repair Activity (SRA). It operates on a 
biweekly frequency and produces time-phased statement of repair requirements in order of prec¬ 
edence and preference, to be accomplished by the SRA. Data for computing the requirement is 
extracted from the Inventory Manager Stock Control and Distribution System, the System Support 
Manager Stock Control and Distribution System, and the D041 World-Wide Category I and II R 
Requirements Computation System. The resultant computation produces levels of Safety, Re¬ 
pair Check Point, Repair Projection Point, and Maximum Repair Projection. All available 
wholesale assets and due-in quantities are then allocated to these levels. Deficiencies in each 
level become repair requirements by precedence. The above computation is made for each 
family of items, giving full consideration to the interchangeability of their parts, thereby estab¬ 
lishing the preference for repair. 


From Cat. 1 and HR 
Requirement# 
Computation 
Syatem (D041) 


From Syetem Support 
Manager Stork Control 
and Dietribution Syetem 
(D034) 


From Inventory 
Management Stock 
Control and 
Dietribution 
Syetem (DO32) 


From Worldwide 
Stock Balance and 
Coneumption Report 
Syetem (DI04) 
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HARDWARE: 



2-IBM 7080’a 



4-1BM 1401 'a 



1 -IBM 1401 


Com¬ 

puter 

Firat 

Deliv- 

M*o7vr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(a*) 


External 

Storage 

Peripheral Devicea 

Car. 

Reader/Punch 

Printer 

Internal Sto 

rage 

No. 

Read 

Speed 

(carda/ 

min) 

Punch 

Speed 

(carda/ 

min) 

No. 

Speed 

(1pm) 

Cycle 

Time 

(U»L 

Char. 

Sise 

(bit.) 

Char. 

Ca¬ 

pacity 

No. 

Mag. 

Tapea 

Trana. 

Rate 

2-IBM 
7080 

9/61 

Char. 

li 

2 

6 

160.000 

20- 
729 VI 

to 

90K 

None 

— 

... 

None 


4-IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

8.192 

2- 

729 IV 

22.5K- 
62.5K 

1- 

1402 

800 

250 

1- 

1403 

600 

IBM 

1401 

9/60 

Char. 

230 

11.5 

6 

8.192 

4- 

729 II 

15K- 
41.6K 

1- 

1402 

800 

250 

1- 

1403 

600 


Comment: The equipment configuration varies with the installation both between AMA's 
and Hq AFLC. The configuration depicted above is for the San Antonio AMA. 
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SOFTWARE : Software for both the IBM 7080 and IBM 1401 computers consisted of an Autocoder 
assembler and general input and output utility routines. The IBM 7080 also had a sort program 
available. 

COMMENT: The software is maintained by IBM. Only canned programs are used on the IBM 
1401 for RRC. 


APPLICATION PROGRAM DEVELOPMENT : Due to the extreme importance of this effort, the 
development was assigned to a task group under the direction of the Data Management Division, 
Hq. AFLC. Maintenance, supply, and report management were the three functional areas using 
the system. Therefore, the task group assigned to development organized itself along lines 
responsible to these three areas. This put the developers in contact withtheusers to facilitate 
design. The analysts were then related directly to the mission groups. Personnel to staff 
the development group were brought in from five AMA's; also, one IBM programmer was used. 
Four categories of people were in the development group. First, there were the conceptual 
types who established the system policies and guidelines. Second, there were procedural 
people who specified operating instructions. Third, there were analysts who translated the 
policy and procedure requirements into specifications for programmers. Finally, there were 
programmers who coded the system. No special management techniques were used to control 
the development of the system. Status reporting to Headquarters was done on a monthly basis. 
The programs were written in Autocoder II to operate on hardware already existing at all the 
AMA's. All of the IBM 1401 software consisted of canned library routines. The programs were 
checked out individually at WRAMA or SAAMA with the system test following at SAAMA only 
for 4 months. Program test time was broken down into 223 hours for the IBM 1401 and 135 
hours for the IBM 7080. System test time is unknown since system test was done with live 
data and considered to be production in some instances. 


FILE CONVERSION: No file conversion was involved in RRC because the system was designed 
to operate on existing files. 
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DOCUMENTATION : The principle documentation for this system is as follows: (1) AFLCL 
300-11, App. 1 (a user's manual for D073 prepared by the repair agencies; and AFLCL 300-11, 
App, 2 (operating instructions for D073), This is a complete maintenance manual which in¬ 
cludes flow charts and format layouts. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
System 

In ADP 

In Area 

Of College 

Development 

Manager 

1 

3 

15 

15 

Unknown 

Analyst 

1 

3 

10 

10 

Unknown 

Programmer 

2 

19 

Unknown 

Unknown 

Unknown 

Operations 

Manager 

4 

0.1 

Unknown 

Unknown 

Unknown 

Operator 

89 

0.4 

2 

Unknown 

XT 


OPERATIONS : The computer operation is staffed at SAAMA 24 hours a day, 7 days a week. It 
operates as a closed shop. RRC is one of many applications on the IBM 7080's and 1401's, A 
daily schedule is followed by the installation which is displayed on closed circuit TV. Five IBM 
1401 computers are used to process RRC. The pie chart below reflects utilization as if one IBM 
1401 did all of the RRC application processing, and not all five computers, which is actually the 
case. 

Comment : None. 

Off 

98 hr* I 3% 

Schd Mt 
43 hr* 6% 

Mach Error Lost 
11 hr* 2% 

Unnrhd Mt 
4 hr* 1% 

Idle 
24 hr* y% 

Set Up 
66 hr* 9% 

Chg Lost (allother 
•pps) 6 hr* 1% 

Prog Dev » Mt 
(all other app*) 

10 3 hr* 14% IBM 7080 (A) 





Prod (RRC 
app) 1 5 hr* 2% 
Prog Dev * Mt 
(RRC app) 

1 hr* 1% 

Prod (ail other 
*pp«) 3 36 hr* 46% 


Prog Dev 6 Mt 
(all other app*) 
77 hr* 11% 


APPLICATION PROGRAM MAINTENANCE : Program maintenance for RRC is currently per¬ 
formed at Headquarters AFLC by three personnel of the Data Management Division. There are 
an analyst and a programmer at each AMA to monitor the operation of the system and to in¬ 
stall program corrections received from Headquarters AFLC. 

COMMENT: None. 
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BENEFITS : Proposed : RRC was to assist AFLC inventory management by identifying the items 
and quantities to be repaired in order to maintain inventory levels. An additional benefit from 
RRC was to be the production of a biweekly schedule of repair requirements to be accomplished 
by Specialized Repair Activities. Repairs were to be scheduled in order of precedence and pref¬ 
erence to improve control and management of repairable carcasses. 

Actual: RRC provided management tools to AFLC which had not formerly existed. It provided 
scheduling and control of repair activities not possible prior to RRC implementation. 


COST FACTORS: 


Man-Montha of Development Effort (Dev.) 

Proposed: Unk CZ 

Actual: 8 ■■■■■■■■■■ 

Comment - A DAP for RRC wu submitted to AFADA in March 1965 and 
immediate verbal approval was given by AFADA for a 6-month effort. 
There was no estimate for man-months of development effort stated In 
the DAP. 

Months of Elapsed Development Time (Dev.) 

Proposed: 4 1 "i 

Actual: 4 ■■■■■■■■■■ 

Comment : The proposed Initial operational capability date was 

TuneTTSV 

Doliars of Hardware Cost for Program Checkout (Dev.) 
Proposed: Unk CZ 

Actual: 62.190 

Comment : Program checkout required 135 hours on the IBM 7080 com- 
puterVnd 233 hours on the IBM 1401 computer. 

Hours/Month of Hardware Use for Application Production (Op.) 

Proposed: 20 1 1 

Actual: 4 Mfl 

Comment : The actual number reflects usage during March 1966 on the 
IJBM 7060 at SAAMA. Fifteen hours were used for RRC application 
production on the peripheral IBM 1401's. The DAP stated an estimate 
of 30 hours/month per AMA for RRC application production on the 
IBM 1401 computer. 


FUTURE PLANS : A number of modifications and minor corrections are being incorporated in 
what is known as a "block change.” A "block change" in a system is an extensive revision of 
the programs, procedures, and documentation reflecting an accumulation of minor errors and 
modifications. The modifications reflect efforts to be compatible with the "feeder" systems 
and changes of mission policies and operational environments. These changes are scheduled 
to be operational at all AMA's by September 1966. This "block change" procedure is common 
with the Air Force Logistics Command and this system will probably be modified in the future 
by this procedure. 


Houra/Month of Hardware Uae for Program Maintenance (Op.) 

Propoaed: Unk CZ 

Actual: 0 | 

Comment : The actual number reflecte uaage during March 1966 on the 
IBM 7080 at SAAMA. Program Maintenance for RRC la done only at 
Hq. AFLC. The operational AMA'i have monitor programmer/ 
analyata who collect program error data to aend to Hq. AFLC and tnatill 
correctiona from Hq. AFLC. Seven houra were uaed for RRC program 
maintenance on the peripheral IBM 140l'a. 

Number of Operationa Peraonnel (Op. ) 

Propoaed: UnkC 

Actual: 1 ■■■■■■■■■■■ 

Comment : The actual number of peraonnel la prorated from 89 operator a 
at SAAMA on the baala of machine houra uaed by RRC. 

Number of Program Maintenance Peraonnel (Op.) 

Propoaed: Unk CZ 

Actual: 6 ■■■■■■■■■■ 

Comment : The actual number of peraonnel ia prorated from programmera 
at SAAMA and Hq. AFLC on the baaia of titne devoted to RRC program 
maintenance. 

Dollara/Month of Hardware Coat (Op.) 

Propoaed: Unk CZ 

Actual: 2.859 ■■■■■■■■■■ 

Comment: None. 
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SYSTEM : Appropriation Accounting Remote-Random Access System--SC/ACCT 
(IBM 1410) 


DATA SYSTEM DESIGNATOR: H074 


DATA COLLECTION DATE: May 1966 


LOCATION: 


Contact for Additional Information 

Data Processing Division 

Directorate of Data Systems 

Air Force Systems Command 

Andrews Air Force Base, Maryland 

Development 

Air Force Systems Command 

Andrews Air Force Base 

Maryland 

Maintenance 

Air Force Systems Command 

Andrews Air Force Base 

Maryland 

Pilot Installation 

None 

First Operational Installation 

Air Force Systems Command 

Andrews Air Force Base 

Maryland 

Number of Operational Installations 

10 


FUNCTION : The users of SC/ACCT are the Financial Divisions of the nine Air Force System 
Command (AFSC) Divisions and the Financial Division of AFSC Headquarters. The mission 
of these divisions is financial accounting and reporting the status of funds. SC/ACCT functions 
as a management support system in financial and accounting operations by permitting direct 
inquiry and maintenance of a division's current funding and listing periodic summaries of the 
finance file contents. In addition, accounting information required by the AFSC Headquarters 
and by other commands is provided by the divisions on punched cards and magnetic tape. 


ORGANIZATION: 





(Operator) 
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HISTORY : From August 1959 to January I960, a study of the current posture of the Air Force 
Systems Command's (AFSC) data processing requirements was undertaken. This study re¬ 
sulted in the development of a data processing concept based on the principles of standardi¬ 
zation and compatibility of data systems and equipment. The report was submitted in July 
I960 to Headquarters USAF as a program concept of a total command package. 

The report included the general identification of the data systems to be included in the de¬ 
velopment of the program and a detailed justification for the selection of an IBM 7070/1401 
system for Headquarters AFSC and IBM 1410 systems for the divisions. Accounting and 
finance were among the functions selected for standardized automation and were to be part of 
a complete management system. 

Headquarters USAF directed AFSC to make a reselection of the data processing equipment 
in accordance with a new computer selection policy. The Command ADP program was rewritten, 
approved by Headquarters USAF, and submitted to 16 manufacturers as an RFP in March 1962. 
Two proposals were received and the Headquarters AFSC ADP selection committee recom¬ 
mended the selection of the IBM 1410 to Headquarters USAF which approved the installation 
of one IBM 1410 to be installed at ESD as a pilot system. The 1410 was installed at ESD in 
August 1963, and the conversion of the accounting and finance system began in September. 
Following a Headquarters USAF evaluation of the pilot system, final approval was granted in 
February 1964 to retain the ESD system and to install eight additional 1410's at the AFSC 
divisions. 

Early in 1962, a Data Development Division was established within the Directorate of Data 
Systems at AFSC for the exclusive purpose of developing the command management system. 

The Financial Management Branch's responsibility was to design, develop, and implement an 
ADP system for accounting and finance. The Standards Branch's responsibility was to define 
software in accordance with the system requirement. In addition to Air Force personnel, two 
IBM programmers provided programming support in the Financial Branch developing the in¬ 
quiry system as well as test programs. Air Force personnel in the Standards Branch were 
supplemented by four IBM programmers in the development of the monitor system and vari¬ 
ous other software packages. 

SC/ACCT is operational at Hq. AFSC, Andrews AFB, and at nine AFSC divisions. 


SCHEDULE: 
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DESCRIPTION: The AFSC accounting and finance system provides a standard automated 
accounting system for each division within the command. The system permits direct inquiry and 
maintenance of the division's current financial funds, as well as listing of periodic summaries of 
the file contents. In addition, accounting information required by headquarters and by other com¬ 
mands is provided on punched cards or magnetic tapes. 
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HARDWARE: 



IBM 1410 


Com¬ 

puter 

First 

Deliv- 

ery 

Mo/Yr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(us) 

Internal Storage 

External Storage 

Peripheral Devices 

Card Reader/Punch 

Printer 

Remote 

Consoles 

Mag Tapes 

Disk 

No. 

Mag 

Tapes 

Trans. 

Rate 

No. 

Disks 

Trans. 

Rate 
(char. / 
sec) 

Char. 

Ca¬ 

pacity 

Ac - 

cess 

Time 

(ms) 

No. 

Read 
Speed 
(cards / 
mip) 

Punch 
Speed 
(ca rds/ 
min) 

No. 

Speed 
0 l*m) 

No. 

Speed 

(cpm) 

Cycle 

Time 

(us) 

Char, 

Size 

(bits) 

Char. 

Ca¬ 

pacity 

IBM 

1410 

11/61 

Char. 

68 

4.5 

6 

40.000 

1 or 2 (,) 
7330 

7.2K 

l- 

1301-2 
Model 2 

90.100 

55.9M 

180 

I - 
1402 

800 

250 

I- 

1403 

hOO 

2 or 3 (2) 
1014 

90 


Comment: (1) Six installations have two 7330 tape transports; four installations have one 7330 

tape transport. 

(2) Three installations have three 1014 remote consoles, seven installations have 
two 1014 remote consoles. 
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SOFTWARE : Software for the IBM 1410 consisted of the following: (1) a monitor program de¬ 
signed for this application; (2) a Processor Operating System (POS); (3) a maintainer pro¬ 
gram designed for this application; (4) a sort program; and (5) two utility program packages. 
The software was delivered by IBM with the machine in August 1963, 

Comment: The monitor program resides in core storage at all times, controls the use of 
remotes, and establishes an interface between the analyzer program and the application pro¬ 
grams stored on the disk. The POS provided AUTOCODER, COBOL, and FORTRAN capa¬ 
bilities. AFSC also developed macros for POS giving teleprocessing and monitor communica¬ 
tion capabilities. The sort program has been modified for on-line use by the addition of routines 
to enable interrupt processing and call from another program. Both of the utility program 
packages were recompiled and relocated to convert from tape to the disk system. 


APPLICATION PROGRAM DEVELOPMENT : A Data Development Division was established within 
the Hq. AFSC Directorate of Data Systems for the exclusive purpose of developing AFSC man¬ 
agement systems for the IBM 1410. The Financial Management Branch's responsibility was 
the system design, programming, testing, and documentation of the Appropriation Accounting 
System, The branch chief and his assistant supplied the input formats, the output formats, 
the records formats, and the logical approach for the system design. The two sections of the 
Financial Management Branch then developed the detailed system design and wrote the required 
programs in AUTOCODER. The Standards Branch provided the software within which the sys¬ 
tem was to operate, including the monitor system and software to simulate remote terminals 
which were not available on the test computer. The final system test was done on a computer 
configuration with remote capabilities. Approximately 350 hours, out of a proposed"600 hours 
free test time bid by IBM in the proposal, were used for testing. The programmers were 
allowed to see their test run but they could not operate the computer. Turnaround time was nor¬ 
mally 24 hours or less. (The system test included parallel operations for 1 month.) 


FILE CONVERSION: There were three accounting and finance systems operating at the bases 
prior to the implementation of the 1410 system. One was a manual system, the second was an 
Air Force standard PCAM system, and the third was the Air Force Program Accounting 
System. Besides the three different programs, there were local codes used within each of the 
systems that made even the standard punch card system somewhat unique to each base. Those 
bases with punch card systems were directed by Headquarters AFSC to develop conversion pro¬ 
grams to reformat the local card forms into the new formats used by the 1410 system, as well 
as to convert all local codes into standard codes. These cards were then entered into the sys¬ 
tem by use of the test simulator program to produce the master files. The computer time re¬ 
quired to make the initial file development ran from 18 hours to a matter of days at some bases. 
Those bases that were on manual systems were required to enter all their transactions into the 
system via the remote keyboard. This required as much as a week in some instances. 
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DOCUMENTATION : The documentation includes the narrative description of the system, op¬ 
erator instructions, system flow charts, logic charts, input and output layouts and program 
listings. This information is contained in one manual, AFSC Manual 171-4, 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated 
to System 

In ADP 

In Accounting 

Of College 

Development 

Manager 

4 

2 

7 

1.5 

0.5 

Analyst . 

3 

3 

17 

17 

Unknown 

Programmer 

13 

14 

0.5 

0.5 

Unknown 

Operations 

Manager 

None 

Unknown 

Unknown 

Unknown 

Unknown 

Operator 

7 

9 

4 

2 

XT 


OPERATIONS: The SC/ACCT system is run during regular business office hours. It operates 
as a closed shop. The SC/ACCT system is one of several applications on the IBM 1410 com¬ 
puter at Andrews AFB. 

Comment : The program development and maintenance is done only at Headquarters, AFSC, 
Andrews AFB. The "Other Time" could not be defined. "All other application" program devel¬ 
opment and maintenance is included in application production in the pie chart. 


Other 
135 hrs 18% 

Idle 

189 hrs 26% 


Set Up 
30 hrs 4% 


SC/ACCT 



Prod (SC/ACCT 
app) 165 hrs 2 3% 

Prog Dev & Mt 
(SC/ACCT app) 

28 hrs 4% 

Prod (all other 
apps) 17 5 hrs 24% 

Chg Lost 
(all apps) 

8 hrs 1% 


APPLICATION PROGRAM MAINTENANCE : Two programmers are currently involved in pro¬ 
gram improvements and corrections at Andrews AFB where all program maintenance is 
done. More time is spent on improvement than on correction. 

Comment: None 
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BENEFITS : Proposed: Prior to development of SC/ACCT, three accounting and finance sys¬ 
tems were used at AFSC bases. These systems were either manual or on PCAM. The systems 
also used local codes, causing the systems to be unique to each base. Benefits that were to re¬ 
sult from implementation of SC/ACCT indluded a standard accounting and finance system through¬ 
out AFSC and increased accuracy and timeliness through the use of state-of-the-art data proc¬ 
essing equipment. 

Actual: SC/ACCT was phased into operation at different AFSC divisions between February 1964 
and July 1965. The system was standarized across all divisions, providing increased inter¬ 
changeability of processing capability and personnel throughout AFSC, in addition to simplifying 
the production of command-wide reports. ADP provided more rapid access to accounting and 
financial data than the PCAXl or manual systems, 


COST FACTORS: 


Msn-Months of Development Effort (Dev.) 

Proposed: Unit CZ 

Actual: 226 ■■■■■■■■■■ 

Comment : No DAP was praparad for tha SC/ACCT system. Instead, 
a study group submitted a program concept to Hq. AFSC (*t that time 
Air Research and Development Commend). The study resulted la hard* 
were recommendations end detailed system specifications. 


Months of Elapsed Development Time (Dev.) 

Proposed: 9 i " 1 

Actual: 12 

Comment : Once the design was fixed, the system underwent little re* 
design or modification, either during or after development. It was fait 
by the developers that the planned operational date for the initial Installa¬ 
tion at Andrews ATB was overly optimistic. 


Pollers of Hardware Cost for Program Checkout (Dev.) 
Proposed: Unk CZ 

Actual: 26.52S 

Comment : IBM bid 600 hours free test time worth approximately $40,900 
for entire system checkout. Including system software. The remote query 
had to be simulated, since the test computer had no remotes. This caused 
no problems when actual checkout with remotes was begun. A total of 350 
hours was actually used for program end system checkout. 


Hours/Month of Hardware Use for Program Maintenance (On.) 

Proposed: Unk Q 

20 

Comment : The actual number reflects usage on the IBM 1410 during 
March If66 at Andrews ATB. 

Number of Operations Personnel (Op.) 

Proposed: UnkCZ 

Actual: Unk K 

Comment : There are seven operators allocated to SC/ACCT at 

Andrews ATB. The number of managers allocated to SC/ACCT at 
Andrews ATB is unknown. 

Number of Program Maintenance Personnel (Op.) 

Proposed: Unk CZ 

Actual: 2 ■■■■■■■■■ 

Comment : The actual number represents full-time SC/ACCT maintenance 
programmers at Andrews ATB. 

Dollars/Month of Hardware Cost (Op.) 

Proposed: UnkCZ 

Actual: 13,730 ■■■■■■■■■■ 


Hours /Month of Hardware Use for Application Production (Op.) Comment : None. 

Proposed: Unk CZ 

Actual: 163 

Comment: The actual number reflects usage on the IBM 1410 duxlnc 
March l4b6 at Andrews AFB. 


FUTURE PLANS : Plans for changes or refinements to SC/ACCT are indefinite, with the excep- 
tion of the inclusion of DOD's MILCAP (Military Contract Administration Procedures). MILCAP 
is scheduled for implementation by 1 July 1968. In addition, the advisability of adding civilian 
payroll to the system and incorporating disk checks to improve disk reliability are under study. 
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SYSTEM: SPACETRACK--SPCTRK (Philco 2000) 


DATA SYSTEM DESIGNATOR : A005 
DATA COLLECTION DATE; April 1966 


Contact for Additional Information 

Hq. , Air Defense Command (ADOOP) 

Ent Air Force Base 

Colorado Springs, Colorado 

Development 

Laurence G. Hanscom Field 

Massachusetts 

Maintenance 

Ent Air Force Base 

Colorado 

Pilot Installation 

None 

First Operational Installation 

Ent Air Force Base 

Colorado 

Number of Operational Installations 

1 


FUNCTION : The user of SPACETRACK is CINCNORAD. One of the most important missions 
of the user is the NORAD space surveillance program. SPACETRACK functions as an opera¬ 
tional and intelligence support system to detect, track, and maintain a central catalog of all 
man-made objects in space and provide ephemerides on all such objects. In addition, 
SPACETRACK supplies CINCNORAD with information and data for threat evaluation and de¬ 
cision making and for the operation of SPADATS. SPACETRACK also has the responsibility 
for backup to the NORAD (425E) system for processing BMEWS display information. 


ORGANIZATION: 



(OjmtMoi ) _ _ — — — Information Flow 
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HISTORY : In October 1957 the first man-made orbiting body, Sputnik I, was orbited around the 
earth by the U. S. S. R. At that time the United States capability for tracking orbital elements 
consisted of a private tracking system maintained by Dr. Arthur Leonard, an American astron¬ 
omer. In early 1958, Leonard and two other astronomers, Wahl and Frieden, were brought to¬ 
gether by the Advanced Research Projects Agency (ARPA) in a pilot project of space tracking. 
Late that year, ARPA formalized the project by issuance of order 50-59 establishing a 
"SPACETRACK" filter center at Bedford, Massachusetts. The order also generally defined 
the planning requirements of an operational system to locate, track, and catalog all man-made 
objects in space. In early 1959, the Air Research and Development Command (ARDC) was dele¬ 
egated the SPACETRACK mission and established a central data processing center at 
Laurence G. Hanscom Field, Massachusetts. The Air Force assumed responsibility for the 
system in October i960 and the Air Defense Command (ADC) was designated user. The first 
contingent of ADC personnel began training in the techniques and methods of space detection at 
Hanscom Field in November I960. The first or A system became operational at Ent AFB, 
Colorado, in June 1961. It was followed by the A-l, B-l, B-2, and B-3 systems. Each version 
replaced the previous one (with only partial recoding) and increased the capability of the 
SPACETRACK system. 

The earliest SPACETRACK development was under the direction of the Cambridge Research 
Geophysics Laboratory until early 1961. The astrodynamics and operational programs were 
produced by several universities and by private industry under many small contracts. 

The two leading contractors were Aeronutronics and Wolf Research and Development. There 
was no system concept at this stage and these early efforts were of an R and D nature. 

With the transfer of responsibility to the Air Force in I960, Mitre Corporation was given the 
system engineering task including overall technical responsibility and development of future 
plans. During this period personnel from the Computer Division, Philco Corporation, were 
added to the programming effort, while both Aeronutronics and Wolf Research and Development 
maintained their existing contracts with the Air Force. 

Continuing program additions and modifications have been made since 1961 by the above- 
mentioned contractors, in-house Air Force personnel, System Development Corporation, and 
TRW. 

Before the B-2 system, uniform documentation did not exist for SPACETRACK, although 
system description documents were produced as well as a great deal of program documentation. 
Since implementation of the B-2 system, System Development Corporation has had the respon¬ 
sibility for total documentation of the system and its components. This has resulted in stand¬ 
ardized documentation consisting of several volumes which are updated as the system evolves. 


SCHEDULE: 
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DESCRIPTION: Observations are received via data link from forward sites. If supplying 
BMEWS Display Information Processor (DIP) backup, the data are transferred directly into the 
computer by a special input device (DMNI), BMEWS input data are recorded for later 
SPACETRACK usage. If display output is required, the messages are generated and output 
via a special output device (DMNO). For SPACETRACK functions, input is usually prepared 
by keypunch machines that automatically convert punched paper tape to cards. The processed 
observations are then compared with predicted positions of the orbital elements in the catalog 
and the orbital elements are updated. The corrected orbital elements, sensor acquisition 
data (look angles), and bulletins are prepared for sensors and users. 



146 











































































































SPCTRK Sheet 4 of 7 



147 






























































































































































































SPCTRK Sheet 5 of 7 


SOFTWARE : Software for the Philco 2000-212 consisted of a TAC assembler, an ALTAC com¬ 
piler, and an SYS operating system. The software was delivered by Philco with the hardware 
in October 1 964. 

COMMENT : The ALTAC language is a FORTRAN-like language which includes the capability 
to intermix the TAC assembly language. The ALTAC compiler will accept either ALTAC or 
FORTRAN input statements. The executive system used by 13-3 was developed by SDC, using 
segments of the SYS operating system. SPCTRK and BMEWS programs may occupy the com¬ 
puter simultaneously and be performing their functions over the same period of time in the in- 
terruptable mode of operation. In the noninterruptable mode, SPCTRK occupies the computer 
alone. 


APPLICATION PROGRAM DEVELOPMENT : The first version of SPCTRK was programmed on 
an IBM 709 in a batched processing mode of operation. There was no BMEWS backup capability. 
The A system stems from the translation of programs from the IBM 709 to the Philco 2000. The 
machine language programs were coded in TAC by Aeronutronics Division of Ford Motor Com¬ 
pany, and Wolf Research and Development Corporation under contract to Philco Corporation. 

The FORTRAN programs were modified to comply with ALTAC by Philco Corporation, Com¬ 
puter Division. Aeronutronics was contracted to produce an executive for the Philco 2000 which, 
when coupled with the A system, gave the A-l system. The B-l system included BMEWS backup 
capability and was developed by the System Development Corporation (SDC) to add this capability 
to the A-l system, which was not reprogrammed. The B-2 system, developed by SDC with sup¬ 
port from Aeronutronics and TRW Systems, was a major reprogramming effort. The A-l pro¬ 
grams were rewritten or modified along with the BMEWS backup modules, in order to be tied 
together under a single monitor. The B-2 system developers developed the B-3 system in which 
the B-2 system inputs were standardized and the file formats changed to contain sensor identi¬ 
fication information. The object identification number was also increased from three to five 
digits. The Mitre Corporation served as system engineer and monitored the entire SPCTRK 
development. There are 100 application programs in the B-3 system, broken down by origina¬ 
tors as follows: Aeronutronics, 31; Air Force (including Wolf), 31; Jet Propulsion Laborator¬ 
ies, 3; Philco Corporation (Computer Division) 16; SDC, 14; and TRW, 5. The programs were 
written in the following languages: TAC, 84 programs; ALTAC, 12 programs; and FORTRAN, 

4 programs. SPCTRK was developed under 375 series AFR's. The system test conducted using 
these AFR's was in three phases: (1) the responsible contractor ran programs individually and 
as a system monitored by the System Programming Office (SPO); (2) the SPO ran the system; 
and (3) operational personnel ran the system monitored by the SPO. Records of the number of 
checkout hours do not exist but it is estimated that between 8,000 and 12,000 hours were re- 
quired for development of all systems from A to B-3. _ 

FILE CONVERSION: The only significant file conversion process in the SPACETRACK system 
took place during the switch from the B-2 to the B-3 system. This conversion was necessitated 
by new formats for the files. Among the changes were an increase of the object identification 
number from 3 to 5 digits, in order to be able to track over 999 objects, and increased infor¬ 
mation on the sensors in the Observation (R) File. The files which required conversion were 
the Sensor (S) file, the Observation(R) File, and the Element (E) File. The necessary program¬ 
ming of these conversion programs and the supervision of the conversion effort was performed 
by the Programming Division of the 1st Aerospace Control Squadron. Three hours of computer 
time on the Philco 2000-212 and 1.5 man-months of effort were required to perform this task. 
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DOCUMENTATION : System Development Corporation has the responsibility for complete docu¬ 
mentation. The B-3 System documents have been organized into several series; e. g. , Pro¬ 
gram User’s Manual (TM-LX-193/000/00), Data Base Description (TM-LX-194/000/00), Com¬ 
puter Operator's Guide (TM-LX-192/000/00), etc. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Year* 

Sampled 

Allocated to 
System 

In ADP 

In C and C 

Of College 

Development 

Manager 

None* 1 * 

Unknown 

8.0 

4.0 

5.0 

Analyet 

NonoO) 

Unknown 

5.0 

4.0 

4.5 

Programmer 

20 

Unknown 

3.0 

2.0 

4.0 

Operation* 

Manager 

9 

9 

3.0 

3.0 

4.0 

Operator 

None(0 

51 

2.0 

2.0 

X 


Note: (1) Year* in ADP, C and C, and college were estimated. 


OPERATIONS : The computer operation is staffed 24 hours a day, 7 days a week. It operates as 
an open shop. SPCTRK is the only application on the two Philco 2000 computers. The Philco 
2000 (A) computer is owned, while the Philco 2000 (B) computer is rented. A daily schedule is 
strictly followed by the installation. 

Comment : The chargeable lost time for the two computers was high, mainly because of tape de¬ 
fectiveness and maintenance (44 hours for both computers) of the high-speed Philco 234-2 tape 
drives. Programming and operator errors contributed another 16 hours to chargeable lost time 
hours. Computer utilization was not obtained for the following: Philco 1000, Philco 410, and 
IBM 1620. 


Other 



Prod (SPCTRK only *pp) 
397 hre 54* 


Other 


62 hre 8* 

Schd Mt 
54 hre 7* 

Mach Error Loet 

2 hre 1* 

Unechd Mt 

3 hre 1* 

Idle 

149 hre 19* 

Set Up 
93 hre 13* 


Philco 2000 (B) 



Prod (SPCTRCK only app) 
172 hr* 24* " 


Prog Dev * Mt 
166 hre 23* 

Chg Loet 
29 hre 4f 


APPLICATION PROGRAM MAINTENANCE : There are currently 17 programmers involved with 
program maintenance. Six of these programmers are civilians from Wolf Research and 
Development Corporation. None of these 17 people were involved in the original development 
of the system. It is estimated that they spend 85 percent of their maintenance effort in pro¬ 
gram improvement and 15 percent in program correction. They also act as liaison to those 
programmers at SDC doing major reprogramming (Delta I) and will act as integrators of the 
resultant new system. The turnaround time for checkout never exceeds 8 hours and averages 
5 hours. Checkout is normal priority in this open shop environment. A serious program prob¬ 
lem, however, usually allows the maintenance programmer almost immediate access to the 
computer. 

COMMENT : None. 
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BENEFIT’S : The SPCTRK effort was initially established by the Advanced Research Project 
Car PA) in 1958 to develop a system for cataloging space objects. Precise task requirements 
were not levied but the development effort was run as an R&D program. SPCTRK has evolved 
through a series of major modifications to provide the following benefits not available to the Air 
Force prior to SPCTRK: (1) ability to detect, track, and maintain a central catalog of all man¬ 
made objects in space and provide ephemerides on all such objects; and (2) ability to collect, 
process, analyze, and display information to CINCNORAD to enable threat evaluation and de¬ 
cision making. In addition to the SPCTRK benefits, backup capability is also provided to the 
BMEWS Display Information Processor. 


COST FACTORS: 


M.in-Months of Development Effort (l>v.) 


Hours/Month of llarJwin- Use for Progrim Maintmain (Op..I 


Proposal: Unk CZ 


Proposrd: Unk I / 


Actual 2.424 


Actual: l«fi 


Comment : No formal DAP was prepared for SPCTRK. The responsibility 
of SPCYftK resides with the Air Defense Command (ADC). The approarh 
and tasks were modified several times during development. Theae modi¬ 
fications caused major system design changes, and, hence, the develop¬ 
ment of several new lyatemi, each replacing the previous system. 

Months of Elapsed Development Time (Dev.) 

Proposed: Unk HZ 

-t mmmmmmmmmm 

Comment : The actual number ol months represents the period from April 
1061, when the P2000-2II was Installed at Ent AFR and the A system de¬ 
velopment was begun, to December 1964, when the B-3 system was de¬ 
clared o)»erational. 

Dollars of Hardware Cost for Program Checkout (Dev.) 

Proposed: UnkQ 

Actual: Unk K 

Comment : Urogram checkout records from Hansrom AFR prior In June 
I 'Vl no longer exist. No records were kept on oilier Pliilcn 2001) < urn- 
puters used at Ent AFB and at Aeronutronics. These factors make it 
impossible to determine the computer hours required for SPCTRK program 
checkout. 

Ilours/Month of Hardware INe for Application Production (Op.) 

Proposed: Unk[~~? 

Actual* 

Comme nt The actual number reflects usage during Mari It 1966 on both 
14iilro 2(k)<) (omputers. 


Comment : The actual nmuher reflects usage during March |9nb on both 
I’hilco Z 000 computers. 


Number ol Operations Personnel (Op.) 
Proposed: UnkCZ 


Actual: 

Comment: 
military pi< 

Appro.xim.it 

rmnni'l. 

Number ol 1 

e|y 2/ 1 ol Ibe n tual miniber of personnel an 

‘rogr.un M.itiil'*ii.in« e Personnel (Op.) 

Proponed; 

link CZ 


Ariosi: 



Comment: 

The a« liial i 

•umber ronsists ol 13 military and 7 eivili.tn 

personnel. 




1 foliar 

i / M'Hiili of Hardware C.n.l (tip.) 

1 ‘roposed: 

llnkrz 


Arhial 



Continent; 

None. 



FUTURE PLANS : The SPACETRACK Facility is being moved from Knt A KB, Colorado, to fix 
Cheyenne Mountain Complex, Colorado. During the move, fix* SPACETRACK data is sent 1o 
Ent AFB from the new location via two full-duplex 1200-bit-per-set <>n< 1 data links. The B-3 
system will be replaced by a new system, Delta I, currently being developed by System 
Development Corporation and the Aeronutronics Division of Ford Motor Company. Delta 1 is 
basically the B-3 system with the following changes: (1) improved astrodynamic processes; 
(2) logic changes for near real-time operation of sequences whirl) .ire manual or semiauto¬ 
matic in B-3; (3) priority scheduling by executive control; and (4) new equipment which con¬ 
sists of the real-time system, drum storage, I/O data controller, on-line* high speed printer, 
on-line analyst input typewriter, and an error detection and alarm device. 
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SYSTEM : TAC Command and Control System--TCC (IBM 1410) 


DATA SYSTEM DESIGNATOR: A011D 


DATA COLLECTION DATE: May 1966 and July 1966 


Contact for Additional Information 

Operations Data Division 

Directorate of Planning and Control 
Headquarters, Tactical Air Command 
Langley Air Force Base, Hampton, Va. 

Development 

Headquarters, Tactical Air Command 
Langley Air Force Base 

Virginia 

Maintenance 

Headquarters, Tactical Air Command 
Langley Air Force Base 

Virginia 

Pilot Installation 

None 

First Operational Installation 

Headquarters, Tactical Air Command 
Langley Air Force Base 

Virginia 

Number of Operational Installations 

’l 


FUNCTION : The user of TCC is Headquarters, Tactical Air Command. The mission of the 
user is the management of the Tactical Air Command's resources in training, exercising, eval¬ 
uating, refining, improving, and maintaining a maximum combat readiness to meet any world¬ 
wide contingency requiring operational commitments. TCC functions as an operations support 
system providing the Commander TAC/CINCAFSTRIKE with automated command and control 
support to assist in the effective planning, managing, and controlling of TAC/CINCAFSTRIKE 
resources during normal and emergency situations. 


ORGANIZATION: 



(D«v*lop«r) 
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HISTORY : In December 1962, Headquarters USAF approved a proposal by the Tactical Air 
Command (TAC) for an IBM 1401/1405 system for use in conjunction with the Headquarters USAF 
473L System. The equipment was installed and the 473L programs and data base were loaded in 
April 1963. An abbreviated Data Automation Proposal was approved by Headquarters USAF in 
December 1963 for contract programming to alter the 473L programs for greater responsiveness 
to the operational requirements of TAC. A request submitted by TAC was approved in June 1964 
for an increase in number of personnel to develop an in-house capability to maintain, update, 
and develop programs in support of the TAC Automated Command and Control System. An in¬ 
crease in data processing capabilities was approved and the 1401/1405 system was replaced with 
a 1410/1301 system (operating in 1401 mode) which became operational in November 1965. 

The developmental activity was contracted to IBM who has technical jurisdiction over Air 
Force personnel in this area. The contractor provides training to the military group in order to 
develop an in-house capability. Mixed IBM and Air Force teams are responsible for system 
analysis and program development. The same team carries through from system analysis to 
programming and checkout. Air Force personnel are responsible for the operational usage of 
the machine. Management control methods during development included the statement of work 
and monthly progress reports. The monthly progress reports contain program status and vari¬ 
ances in man-months expended from that budgeted. 


SCHEDULE: 
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DESCRIPTION: The broad functions of the system are called "capabilities"; e. g. , Force Status 
Capability, Airfield Facilities Capability. Each capability is a series of program modules used 
to extract information from the data base and produce reports. In addition, there is a semi- 
English language, called the Query Language, which is an alternate method for using the capa¬ 
bilities of the system. Programs reside on the disk. A small control program is loaded for 
each capability, which then automatically loads and reloads subroutines to process the request. 
Input data are received from TAC units and Hq. USAF and are used to update the data base peri¬ 
odically. Query Language requests may be used either via the computer console typewriter or 
via a TRW real-time console. 


R.ciir.4 vt. 
TTT and 
AUTODIN 



Command Po.t 
and B.ltl. Staff 
P.r.onn.l 


To Other 

Command. 
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HARDWARE: 



Com¬ 

puter 

First 
Deliv¬ 
ery 
Mo / Y ? 

Word 

or 

Clia r . 
Mach. 

Add 

Tim** 

(lIH) 

Internal Storage 

External Storage 

Peripheral Devices 

Card Reader/Punch 

Printer 

Mag Tapes 

Disk 

No. 

Mag 

Tapes 

T rans. 
Rate 

No. 

Disks 

Tr.tns. 

Rat.* 

Char. 
Ca¬ 
pa. ily 

Ac¬ 

cess 

Time 

(ms) 

No. 

Read 
Speed 
(ca rds / 
min) 

Punch 

Speed 

(cards/ 

min) 

No. 

Speed 

0pm) 

Cy. Ic 
Timi' 

( a* 1 

Char. 
Si *e 
(Wit n) 

Char. 
Ca - 
pacity 

I I'M 

11 MI 

Cha r. 

KH 

4.5 

6 

40K 

4- 

22. 5K 

1- 

90,100 

55.9M 

180 

] _ 

BOO 

250 

I - 

600 

1410 







729 IV 

62. 5K. 

1301-2 




1402 



140) 











Mofirl 2 










Comment: Communications Control Console (CCC), built by TRW is used for real¬ 
time display and interogration. Hardware characteristics for this 
equipment are not available. 


154 











































































































TCC Sheet 5 of 7 


SOFTWAR E; Software supplied by IBM consists of the 1401 and 1410 Autocoder assemblers 
and the 1400 series utility routines and software including a general sort/merge. Headquarters 
USAF supplied the executive system used by TCC. 

Comment; None 


APPLICATION PROGRAM DEVELOPMENT ; Two branches in the Operations Data Division at 
Hq. TAC had the developmental responsibilities for the modified 473L system. The System 
Development Branch was mainly concerned with DAP's and future planning, while the Analysis 
^Programming Branch aided IBM Federal Systems personnel in system analysis and program 
development. Because of IBM's experience and the Air Force's lack of experience in this area, 
IBM had technical jurisdiction over Air Force personnel. The programs are divided into three 
major areas; (1) control programs, which perform all disk operations; (2) utility programs, 
which perform the repetitive or common system functions; and (3) capability programs, which 
perform application functions such as file generation and maintenance, information retrieval and 
display, and report generation. The language used was IBM 1401 Autocoder. When the IBM 
1410 was initially installed, the 1401 programs were run in the 1401 mode on the 1410. The 
executive, query language, and file formatting programs were rewritten for the 1410 and 1301 
disk files by Hq. USAF and installed at TAC. Because of the magnitude of the system, the pro¬ 
grams were highly segmented and connective control was provided by the executive control pro¬ 
grams. The checkout computer was freely available during development on an open shop basis. 

A system test was performed by IBM to the satisfaction of TAC. No records were kept of de¬ 
velopment time used for checkout on the computer. Management control was in the form of work 
statements and monthly progress reports. 


FILE CONVERSION; File conversion affects two types of data bases. The non-TAC-specific 
files were furnished by Hq. USAF, along with the 473L system. The TAC-specific files are 
being converted on an ongoing basis. This means that some functions are not completely auto¬ 
mated. The reason for this is insufficient manpower to abstract all operational plans and other 
data from hard copy to punched cards. Consequently, only the high-priority plans and data are 
available to the computer. The function of file conversion rests with the Data Control Branch. 
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DOCUMENTATION : The documentation from the 473L system is used extensively. T AC-specific 
system and program documentation usually serves only to augment an existing 473L document. 


PERSONNEL: 


Activity 

F unction 

Number of People 

Number of Years 

Sampled 

Allocated to 
Sy stem 

In ADP 

In C and C 

Of College 

Development 

Manager 

6 

6 

5.0 

l. 5 

3.5 

Analyst 

10 

7 

4.5 

1.5 

3.5 

Programmer 

ll 

17 

J. 5 

1.5 

3.0 

Ope rations 

Manager 

1 

1 

1.5 

1.0 

4.0 

Operator 

7 

1 1 

7.0 

2. 5 

XT 


OPERATIONS : The computer operation at Langley AFB is staffed as required by workload. It 
operates during the prime time as an open shop. TCC is the only application on the IBM 
1410 computer. A flexible master schedule is prepared each week. 

Comment: None. 


Off 



Prod (TCC 

only app) 220 hrs 30% 


Prog Dev & Mt 
148 hrs 20% 


IBM 1410 


APPLICATION PROGRAM MAINTENANCE : A total of 17 programmers maintain the TCC sys¬ 
tem. Headquarters USAF maintains the 473L programs, but TAC makes and maintains its 
own modifications and additions. Major corrections and improvements are handled by the con¬ 
tractor and developmental teams; minor maintenance runs are readily available with less than 
24-hour turnaround time. Changes are not documented unless they affect the Operational Speci¬ 
fications or the Programming/Coding Specifications. 

Comment : Program maintenance activity is characterized by the continual need for improve¬ 
ments and additions to the system. Continuity is achieved by the contractor whose personnel 
turnover has been low and Air Force personnel turnover has been relatively high. 
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BENEFITS : Proposed : TCC was proposed as an automated command and control support 
system to provide the commander TAC/CINCAFSTRIKE with an effective operational capability 
to plan, manage, and control TAC/CINCAFSTRIKE resources in the execution of its prescribed 
functions, during normal and emergency situations and in a compressed time/space 
environment. 

Actual: TCC was developed as a major modification to the existing Headquarters, USAF, 473L. 
Command and Control System. The system is operational and providing the proposed benefits; 
additional development is required to fully automate the command and control functions. 


COST FACTORS: 


Man-Montha of Davalopmant Effort (Pav.) 

Proposed: UnkCZ 

741 ■■■■■■■■■■ 

Comment : Tha phaaa of davalopmant of tha TCC ayatam dlacuaaad 
Kara wn complatad in accordanca with a DAP prapared on 30 August 
1963 ■pacifically for this davalopmant affort. This DAP propoaad to altar 
tha 473Lprograms, allowing tham to ba mora raaponalva to tha opara- 
tional raquiramanta of TAC. Hq. USAF approvad tha DAP on 9 Dacambar 
1963. 

Montha of Elapaad Davalopmant Tima (Dav.) 

Propoaad: UnkCZ 

Actual: 


Comment : Tha actual davalopmant pariod waa from May 1964 to Juna 
1964 It ancorrpaaaaa tha raplacamant of tha IBM 1401/1405 systam 
with tha IBM 1410/1301 ayatam in accordanca with a DAP praparad on 
5 March 1963 and approvad by Hq. USAF on 11 Juna 1963. 


Dollars of Hardwara Coat for Proiram Checkout (Dev.) 
Propoaad: UnkCZ 


Actual: UnkK 

Comment : No racorda wara kapt of computar use for tha 473L program 
checkout. 


Hours/Month of Hardwara Uaa for Application Production (Op.) 

Propoaad: Unk CZ 

Actual: 120 

Comment: Tha actual number reflects usage during March 1966 on tha 

IBM TTITJ. 


FUTURE PLANS: In reply to a DAP dated 26 november 1965, Headquarters USAF proposes 
that the IBM 1410 ADP System will be used until December 1968 and not be replaced between 
July 1967 and January 1968 as currently scheduled by DOD. In FY 67 an automatic communica¬ 
tions processing center, with an AUTODIN terminal which will initially be utilized for testing 
AUTODIN capability, will be installed at Headquarters TAC. I/O device testing is proposed 
throughout FY 67 to determine feasibility and desirability of placing I/O devices at USAF Head¬ 
quarters and selected Division/Wing Command Posts. I/O devices, if approved by Headquarters 
USAF, will be purchased and installed at all TAC bases in FY 69, making the TAC bases capable 
of receiving information from the Headquarters TAC system. Subsequent to the installation of 
the USAF-designated standard computer to replace the interim IBM 1410, this system will be 
converted to the new computer, probably during the last half of FY 69. It is also proposed that 
the USAF-designated standard computer equipment and an automated communications terminal 
be installed at USAF Headquarters and selected Division/Wing Command Posts in FY 70. 


Hauaa/Month of Hardwara Dm for Proiram Maintananca (Op.) 

Propoaad: Unk f~7 

Actual: 14S 

Commant : Tha actual numbar raflacta uaaga during March 1966 on tha 
IfeM 1410. 

Numbar of Oparatlona Paraonnal (Op.) 

Propoaad: Unk CZ 

Actual: 11 ■■■■■■■■■ 

Commant : Tha actual numbar of paraonnal la for oparatora only. 

Numbar of Program Malntananca Paraonnal (Op.) 
Propoaad: Unkr~7 

Actual: 

Commant : Tha actual numbar of paraonnal rapraaanta programmara 
only. YKara ara alao 7 analyata and 6 managara aliocatad to TCC V 

Pollara/Month of Hardwara Coat (Op.) 

Propoaad: Unk CZ * 

Actual: 36.054 ■HHI 

Comma nt: Nona. 
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SYSTEM: Standard Base Level Automated Inventory Control System-- 1050/BSS 
(UNIVAC 1050-11) 


DATA SYSTEM DESIGNATOR: D002A 


DATA COLLECTION DATE: May 1966 


Contact for Additional Information 

Headquarters Command 

Bolling Air Force Base 

Washington, D. C. 

Development 

Bolling Air Force Base 

District of Columbia 

Maintenance 

Bolling Air Force Base 

District of Columbia 

Pilot Installation 

None 

First Operational Installation 

Bolling Air Force Base 

District of Columbia 

Number of Operational Installations 

150 planned, 75 currently in operation 


FUNCTION: The users of 1050/BSS are the Base Supply offices at approximately 75 Air Force' 
bases. The mission of the users is controlling the distribution, ordering, and inventory level 
for spare parts, equipment, and other supplies required by base activities. 1050/BSS func¬ 
tions as a management support system to establish a standard automated inventory control 
system at worldwide Air Force bases. The functions performed by the system include requisi¬ 
tioning, receipt, issue, stock control, turn-in, disposition, reporting, and accounting. The 
system responds immediately and fully to all transactions as they occur and provides standard, 
comparable reporting of data for use by all management levels. 


ORGANIZATION: 


r 


DCS/Sy atrm* 

and Logistics 

I 

Directorate of Supply and Service* 



Supply Syatema Design Office 


ZD 


Voinpf mile t 


Directorate of Data Automation 

1 

Directorate of Accounting and Finance 




Data Automation Dealgn Office 





Data Syetem* Control Office 


Accounting and Finance Dealgn Offtr* 


(Developer) 


Development 


I 

I 

Group __ _ _ J 


(Developer) 


(Developer) 


Major Air Comnundi 

I- 


AF Baaea 
~~1 - 


Base Supply Office 


(Operator/Uaef) 
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HISTORY ; By 1962 each major air command had independently developed its own automated base 
“ supply system. It was apparent that the following problems existed; (1) Headquarters USAF 
could not determine the impact of supply policy changes throughout the Air Force; (2) standard 
supply management data were lacking; (3) personnel training was inefficient; (4) multiple- 
development efforts were wasteful. Supply procedures were standardized in an attempt to solve 
these problems, but it soon became apparent that equipment standardization was necessary for 
any significant improvement to be realized. In July 1962, a comprehensive plan was developed 
to establish a standard ADP program for base level material operations. The plan was 
approved in October 1962. 

Systems specifications were developed by the Directorate of Supply and Services, Head 
quarters USAF assisted by personnel from Headquarters, Air Force Logistics Command 
(AFLC). In February 1963 the specifications were released to industry. Proposals were re¬ 
ceived and, in November 1963, the Air Force announced that Sperry-Rand Corporation had been 
selected to provide approximately 150 base-level supply activities with a standard configuration 
of data processing equipment. 

System design of the Standard Air Force Base Level Supply ADP System, which would be 
implemented Air Force-wide by March 1966, began in December 1963 at Andrews AFB. 

A Central Development Group under Headquarters USAF was formed with the responsibility 
for program development, implementation, and maintenance. The group was comprised of a body of 
supply personnel under the direct control of the Director of Supply and Services, Headquarters, 
USAF, and of programmers under the Director of Data Automation. After the programs were 
written and tested, they were implemented at Andrews AFB. Simultaneously with the latter 
phases of writing, testing, and implementing at Andrews, training of Major Air Command 
personnel began. After a trial operational phase, the programs were evaluated and necessary 
changes and improvements were made. With the completion of the changes and improvements, 
the other bases became operational at the rate of 10 installations per month. 


SCHEDULE; 
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DESCRIPTION: The 1050/BSS computer system is controlled by an executive routine which is 
always in memory. This routine examines the input request, either supply or accounting/ 
finance, and calls the required processing programs and data from the disk. The programs 
are operated, the data file is accessed and modified if necessary, a history of the processing 
is recorded on magnetic tape, and the output response is sent. The inputs and outputs, except 
for the printer, are buffered and controlled by interrupts. In addition to normal processing, 
the system produces management reports and performs the accounting and finance functions 
associated with the supply system. 


Transactions arc Received Via 
Radio, TTY, Hand Carrying or 
Direct Remote Console Input 
From Supply Offices 



Counters, etc. 
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HARDWARE: 



Unlvac 1050 (Configuration "B") 


Com¬ 

puter 

Flret 

Deliv- 

MoVvr 

Word 

or 

Char. 

Mach. 

Add 

Time 

(ua) 

Internal Storage 

External Storage 

Peripheral Device 

Card Reader/Punch 

e 

Printer 

Mag Tapee 

Drum 

No. 

Mag 

Tapee 

Trane. 

Rate 

No. 

Drume 

Trane. 

Rate 

(char./ 

eec) 

Char. 

Ca¬ 

pacity 

Ac- 

ceee 

Time 

(me) 

No.' 

Read 

Speed 

(carde/ 

min) 

No. 

Punch 

Speed 

(carde 

min) 

No. 

Speed 

0pm) 

Cycle 

Time 

(ue) 

Char. 

Sice 

(bite) 

Char. 

Ca¬ 

pacity 

Uni vac 
1050 

9/63 

Char. 

117 

4.5 

6 

20.480* 1 * 

1- 

1071 

23K 

1- 

1057-4 

156 

66M U) 

35 

1- 

1051 

400 

1- 

1052 

300 

1 - 
1053. 

900 


Comment!: (1) C configuration systems have 24,516 core storage. 

(2) A configuration systems have 33M character drum storage. 

(3) Three different configurations are used depending on workload at the installation: 

A configuration has 33M character drum storage, 20,480 core storage. 

B configuration has 66M character drum storage, 20,480 core storage. 

C configuration has 6M character drum storage, 24,576 core storage. 
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SOFTWA P E: Software for the UNIVAC 1050 consisted of the following: (1) PAL card and tape 
assembly language systems; (2) input and output utility programs; (3) library maintenance 
and sort programs; (4) FASTRAND tape utility programs; and (5) an executive control system. 
Portion of the software were delivered by UNIVAC at different times between February and 
July, 1964. 

Comment : The executive system did not have adequate restart/backup/recovery capability 
nor did It provide' automatic response to remotes. Considerable reprogramming of the ex¬ 
ecutive system was required to provide these capabilities. The resultant system had many 
bugs and this hindered development considerably. The executive system was not considered 
acceptable until approximalely one year after delivery. No major problems were experienced 
with any of the other software packages. 


APPLICATION PROGRAM DEVELOPMENT: A Central Development Group was established by 
the Air Stall to operate under Hq. _ USAF aFBolling AFB. This group was responsible for pro¬ 
gram development, implementation and maintenance. The group was comprised of a permanent 
body of supply personnel under the direct control of the Directorate of Supply and Services, Hq. 
USAF, and of computer programmers under the Directorate of Data Automation. A short time 
later, it was decided to incorporate Accounting and Finance functions into the system, leading 
to the inclusion of permanent members to the group from the Directorate of Accounting and 
Finance. In view of the magnitude of the system, it was further decided to augment the group 
with vendor personnel and representatives from the Major Air Commands. A project manager 
was selected from the Directorate of Data Automation to direct the development and implementa¬ 
tion at the first 10 bases. This project manager was scheduled to be replaced after the tenth 
base's implementation by a man from the Directorate of Supply and Services, but this has not 
occurred yet due to the many changes and corrections currently going on. 

A test computer was available at Bolling AFB on a continuous 24-hour-a-day basis ex¬ 
clusively for this system's checkout. Each programmer was required to run his own tests for 
a period of six months in order to become sufficiently familiar with the computer operation to 
ensure successful field implementation. This policy resulted in console debugging which, 
coupled with the fact that no programmers had any UNIVAC 1050-11 or disk file storage experi¬ 
ence, led to extensive computer checkout time. There were no formal test procedures. Test 
decks were prepared to test the programs, which were all written in PAL assembly language. 

A team from the Central Programming Group at Bolling AFB was sent to the first base to be 
converted within each Command to aid in conversion. After receiving this support for the first 
base, the Command was responsible for aiding the remaining bases. 


FILE CONVERSION: There were 16 different base level supply inventory systems in the 
Air Force prior to the UNTVAC 1050-11 implementation. These included card systems (PCAM), 
three different RAMAC 305 systems, a 1401 card system, a 1401 tape system, GE 225, 
Burroughs 220, etc. All these systems, however, did have a common element in the punched 
card. The conversion process consisted of a download (preparation of a complete file of 
punched cards) and an upload (reading the punched cards into the 1050). There were over 
160 different types of inputs which could be entered into tm; systems, which presented sufficient 
complexity to require 40 conversion programs to be written. UNIVAC was responsible for 
writing the majority of these conversion programs with the aid of three Air Force programmers 
(UNIVAC provided seven or eight). A team from the central programming group at Bolling was 
sent to the first base to be converted within each Command to aid in conversion. The Command 
was responsible for aiding the remaining bases. 


/ 
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DOCUMENTATION : The system is well documented in Air Force Manuals 77-206, and 67-1. 


PERSONNEL: 


Activity 

Function 

Number of People 

Number of Years 

Sampled 

Allocated to 
System 

In ADP 

In Supply 

Of College 

Development 

Manager 

18 

27 

2.5 

15.0 

Unknown 

Analyst 

35 

40 

0.5 

4.0 

Unknown 

Programmer 

23 

36 

2.0 

4.0 

U nknown 

Operations 

Manager 

None 

Unknown 

U nknown 

Unknown 

Unknown 

Operator 

None 

7.7 

U nknown 

Unknown 



OPERATIONS: All operational sites operate independently. The pie chart represents usage on 
a "iJ" computer configuration at Andrews AFB. All operational sites operate as closed shops, 
and are staffed as required by workload. 

Comment: None. 


Other 
122 hrs 16# 

Off 

65 hrs 9# 

Schd Mt 
15 hr s 2# 
Idle 
12 hr s 2# 

Chg Lost 
12 hrs 2 # 



Prod (BSS only app) 
504 hrs 69# 


UNIVAC 1050-U 


APPLICATION PROGRAM MAINTENANCE : The program maintenance activity is carried on by 
68 programmers in the Central Programming Group at Bolling AFB. There are no maintenance 
programmers at the operational bases. The operators, having attended a two-week program¬ 
ming course, locate problem areas when possible, and send details to Bolling. The operators 
are not allowed to change any program unless specifically directed by the Central Programming 
Group. Currently, it is estimated that 80 to 90 percent of the program maintenance activity 
is correction of existing programs with the remaining time spent on new programs. 

Comment: None. 
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BENEFITS : Proposed: Benefits proposed to come from development and implementation of 
1050/BSS include (1) standardization of automated inventory control systems at approved bases, 
(2) reduced need for system analysis and design through minimizing the number of authorized 
inventory control automation efforts; (3) greater discipline in enforcing supply policy; (4) de¬ 
velopment of standard training courses enabling supply personnel to be used immediately in 
any command; and (5) generation of standard comparable management data for use at all man¬ 
agement levels. 

Actual: The proposed benefits have been realized with the implementation of 1050/BSS. In the 
course of development, a number of additional features such as accounting for materiel re¬ 
sources were added to the system. 


COST FACTORS: 


Man-Months of Development Effort (Dev.) 

Proposed: 300 | 1 

Actual: 1,400 ■■■■■■■■■■■ 

Comment : No DAP was prepared tor the Base Level Supply System. In¬ 
st eaJ] fn July 1962, » comprehensive plan was developed within the Mate¬ 
rial Automation Branch of Hq. USAF for the establishment of a standard 
ADI' program for supply systems. This plan was approved byHq. USAF 
and further development led to the purchase of the UNIVAC 1050 U com¬ 
puter (or approximately 150 base level supply systems. 

Montiis of Elapsed Development Time (Dev.) 

Proposed 10 1 I 

18 

Comment The *ystrm development began In November 1963 and ended 
in April Pl65. 

Dollars of Hardware Cost for Program Checkout (Dev.) 

Proposed: Unk Q 

Actual: Unk W 

Comment : The checkout computer wan available on a continuous 24-hour 
a-day f>a sis. The number of hours used for program checkout was not 
available. 

ilours/Month of Hardware Use for Application Production (Op.) 

Proposed: Unk CZ 

Actual: 504 

Comment : The actual number reflects usage during a recent representative 
month on the "B" configuration of the UNIVAC 1050 II at Andrews AFB. 


Hours/Month of Hardware U»t for Program Maintenance (Op. ) 

Proposed: Unk CZ 

Actual: Unk K 

Comment : AH program maintenance la dnne at Bolling AFB on a ‘•C’* 
configu ration. 

Number of Operations Personnel (Op.) 

Proposed: Unk CZ 

Actual: 7.1 

Comment: The .o tual number of personnel is prorated from operators at 
Andrews - AFB on the basis of machine hours for 1050/BSS. 

Number of Program Maintenance Personnel (Op.) 

Proposed: link CZ 

Actual- h« 

Comment: The actual number of personnel consists of 34 analysts and 
t r programmers at Bolling AFB. All program maintenance Is Hone by the 
Central Programming Group at Bolling AFB. There are no maintenance 
programmers at the other base*. The operators have been trained lo In¬ 
sert program rorrcilion. from Bolling AFB. 

Dollars/Month of Hardware Cost (Op.) 

Proposed: Unk f~7 

Actual: 2,*iVH 

Comment : 1 he actual dollar amount reflects the " B ' configuration ai 
Andrew* AFB lor production only. 


FUTURE PLANS : The 
150 bases projected, 
month. The expected 
of the implementation 


system is currently operational at about half of the approximately 
The implementation is expected to continue at about 10 bases per 
system lifetime is six years. Future plans other than the completion 
schedule are unknown at present. 
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IV. GLOSSARY 


This glossary consists of two primary sections. The first section 
is a general glossary of Air Force and data processing terms. This sec 
tion is based on the Bureau of the Budget (BOB) Glossary of Automatic 
Data Processing. Definitions have been freely modified to reflect the 
specific meaning of terms used throughout this project. A number of 
terms not defined in the BOB glossary are included here. 

The second section is a glossary of cost factors and workload de¬ 
scriptors. Cost factors appear in the Cost Factors section of system 
descriptions and in the cost estimation iso-graphs, while workload de 
scriptors appear in the Workload section of the system descriptions and 
in the cost estimation iso-graphs. 

A. Glossary of Air Force and Data Processing Terms 
ADC Air Defense Command 


ADP 

Automatic data processing; data processing 
performed by a system of electronic or elec¬ 
trical machines so interconnected and inter¬ 
acting as to reduce to a minimum the need 
for human assistance or intervention. 

ADPS 

Automatic data processing system. (See "Sys¬ 
tem, Automatic Data Processing.") 

AF 

Air Force 

AFADA 

Air Force Director of Data Automation 

AFAFC 

Air Force Accounting and Finance Center 

AFLC 

Air Force Logistics Command 

AFM 

Air Force Manual 

AFO 

Accounting and Finance Office 

AFR 

Air Force Regulation 

AFSC 

Air Force Systems Command (formerly ARDC) 

ALGOL 

Algorithmic Oriented Language; an international 
procedure-oriented language. 
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Algorithm 

A prescribed set of well-defined rules, or a 
process, for the solution of a problem in a 
finite number of steps; e.g., a full statement 
of an arithmetical procedure for evaluating 
sin X to a stated precision. 

AMA 

Air Materiel Area 

Analyst, System 

(See "System Analyst.") 

Application 

The system or problem to which a computer is 
applied. 

Application 

Preparation 

Any computer processing, such as file conver¬ 
sion, required to allow an application to be run. 

Application 

Production 

Any computer processing resulting in the gen¬ 
eration of output to the application user(s). 

ARDC 

Air Research and Development Command 
(currently AFSC) 

ASD 

Aeronautical Systems Division of AFSC 

Assemble 

To prepare a machine language program from 
a symbolic language program by substituting 
absolute operation codes and addresses for 
symbolic operation codes and addresses on a 
one-for-one basis. Normally performed by a 
computer program called an assembler. 

Assembly 

Language 

The machine-oriented programming language 
(e.g., FAP, EASY) belonging to an assembly 
system. 

ATC 

Air Training Command 

AUTODIN 

Automatic Digital Information Network; a 
computer-based communication network pri¬ 
marily used by the Air Force, but also used by 
other agencies of the Federal Government. 

Capacity, Storage 

The amount of data that can be contained in a 
storage device. 

Card, Master 

A card containing fixed or indicative information 
for a group of cards. It is usually the first card 
of that group. 
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CBPO 

Consolidated Base Personnel Office; Air Force 
organizational element responsible for base- 
level personnel functions. 

Channel 

(1) A path along which signals can be sent (e.g., 
data channel, output channel); (2) the portion of 
a storage medium that is accessible to a given 
reading station (e.g., track, band). 

Character 

One symbol of a set of elementary symbols, such 
as those corresponding to the keys on a typewriter. 
The symbols usually include the decimal digits 0 
through 9, the letters A through Z, punctuation 
marks, operation symbols, and any other single 
symbols a computer may read, store, or write. 

A character will normally be represented by a 
combination of six bits. 

Chart, Flow 

A graphic representation of the major steps of 
work in process. The illustrative symbols may 
represent documents, machines, or actions 
taken during the process. The area of concen¬ 
tration is where or who does what rather than 
how it is to be done. 

Chart, 

Logical Flow 

A detailed solution of the work order in terms 
of the logic, or built-in operations and charac¬ 
teristics, of a specific machine. Concise sym¬ 
bolic notation is used to represent the informa¬ 
tion and describe the input, output, arithmetic, 
and logical operations involved. The chart 
indicates types of operations by use of a stand¬ 
ard set of block symbols. A coding process 
normally follows the logical flow chart. 

Chart, 

Systems Flow 

A schematic representation of the flow of infor¬ 
mation through the components of a processing 
system. 

Checkout 

(1) A general term for a set of routines designed 
to provide the programmer with a complete eval¬ 
uation of his program under operating conditions; 

(2) the process of checking out a program to en¬ 
sure successful operation under all conceivable 
conditions. 

Closed Shop 

(See "Shop, Closed.") 

COBOL 

Common Business Oriented Language; a busi¬ 
ness data processing language. 
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Compile 

To prepare a machine language program from a 
computer program written in another program¬ 
ming language by performing the usual functions 
of an assembler and also by making use of the 
overall logical structure of the program or gen¬ 
erating more than one machine instruction for 
each symbolic statement or both. 

Compute 

A computer processing function that performs 
logical, arithmetic, and decisional operations 
on data. 

Computer- Limited 

Pertaining to a situation in which the time re¬ 
quired for computation exceeds the time required 
to read inputs and write outputs. 

Configuration 

A group of machines that are interconnected 
and programmed to operate as an interacting 
assemblage. 

Control 

A computer processing function that expedites 
all other computer processing functions; e.g., 
job scheduling, priority handling, segment 
overlaying, data management, and hardware 
assignment. 

Conversion 

(1) The process of changing information from 
one form of representation to another, such as 
from the language of one type of machine to that 
of another or from magnetic tape to the printed 
page. (2) The process of changing from one 
data processing method to another or from 
one type of equipment to another; e.g. , 
conversion from punch card equipment to 
magnetic tape equipment. 

CPU 

Central Processing Unit; that part of a com¬ 
puter system containing the arithmetic unit, 
execution control, and special register groups. 

DAP 

Data Automation Proposal; a document that 
must be prepared and submitted to AFADA for 
any proposed new data automation or major 
change to an existing automated system. 

Data 

A general term used to denote any or all facts, 
numbers, letters, and symbols, or facts that 
refer to or describe an object, idea, condition, 
situation, or other factors. It connotes basic 
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elements of information that can be processed 
or produced by a computer. 


Data, Test 

A set of data developed specifically to test the 
adequacy of a computer program or system. The 
data may be actual data that have been taken from 
previous operations or artificial data created for 
this purpose. 

Data, Transaction 

A set of data in a data processing area, a rec¬ 
ord of occurrence of a new event or transaction, 
in which the incidence of the data is essentially 
random and unpredictable. Hours worked, quan¬ 
tities shipped, and amounts invoiced are ex¬ 
amples from the areas of payroll, accounts re¬ 
ceivable, and accounts payable, respectively. 

Data Base 

A collection of files containing unique informa¬ 
tion; these files are accessible to an ADPS. 

The files of a data base are normally referenced 
or updated with relatively high frequency. Reor¬ 
dered files are not included in the data base. 

Data Base 

Growth Rate 

The amount by which the size of the data base 
will increase over a specified period of time, 
normally measured in percentage of data base 
current size per month. 

Date, Delivery 

The date of physical delivery on site of the 
components of the computer configuration with¬ 
out regard to whether or not they have been un¬ 
packed, placed in final position, or intercon¬ 
nected. Delivery of equipment carries no 
connotation of operational status. 

Date, Installation 

The date new equipment is ready for use. The 
commencement of rental normally begins on 
the day following the date on which the con¬ 
tractor officially notifies the using organiza¬ 
tion that the equipment is installed and ready 
for use, subject to the acceptance and standard 
of performance provisions of the applicable 
contract. 

Debug 

To isolate and remove the mistakes from a rou¬ 
tine in a program or malfunction from a computer 

Design, Functioned 

The specification of the working relations be¬ 
tween the parts of a system in terms of their 
characteristic actions. 
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Development Phase 

The period of time from the date system design 
for the ADPS is begun to the date the system is 
declared operational. During this phase, such 
activities as detailed system design, program¬ 
ming, checkout, and equipment installation are 
accomplished as required. 

Device, Input 

A machine that translates data to be processed 
from coded representations; e.g., punch cards 
or paper tape to electric impulses for use by a 
computer. 

Device, Output 

A machine that translates the electrical impulses 
representing data processed by the computer into 
permanent results, such as printed forms, punched 
cards, and magnetic writing on tape. 

Device, Storage 

A machine into which data can be inserted, in 
which data can be retained, and from which data 
can be retrieved. 

Documentation 

The group of techniques necessary for the orderly 
presentation, organization, and communication of 
recorded specialized knowledge in order to main¬ 
tain a complete record of reasons for changes in 
variables. Documentation is necessary not so 
much to give maximum utility as to give an un¬ 
questionable historical reference record. 

DOD 

Department of Defense 

DSAP 

Data System Automation Program; the official 
data automation program of USAF. It provides 
a coordinated and common basis for planning, 
designing, and operation of USAF ADP systems. 
Each major data automation is assigned a four- 
or five-character DSAP designator. The first 
character of the designator is alphabetic and 
indicates the major functional area of the 
automation. 

El ernont, Data 

A specific item of information appearing in a 
set of data. For example, in the following set 
of data, each item is a data element: the quan¬ 
tity of a supply item issued, a unit rate, an 
amount, and the balance of stock items on hand. 

Element Error 

Rate 

The ratio of the number of elements incorrectly 
received to the total number of elements sent. 
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Equipment, 

Off-Line 


Equipment, 

On-Line 


Error, Data 

Error, Machine 

Executive 
Facsimile (FAX) 

Field 

Field, Card 

File 


The peripheral equipment or devices not in di¬ 
rect communication with the central processing 
unit of a computer. Synonymous with auxiliary 
equipment. 

Descriptive of a computer system and of the pe¬ 
ripheral equipment or devices in a computer 
system in which the operation of such equip¬ 
ment is under control of the central processing 
unit (CPU), and in which information reflecting 
current activity is introduced into the data proc¬ 
essing system as soon as it occurs. Thus, di¬ 
rectly in-line with the main flow of transaction 
processing. Related to on-line processing. 

A deviation from correctness in data, usually 
an error, which occurred prior to processing 
the data. 

A deviation from correctness in data resulting 
from an equipment failure. 

(See "Routine, Executive.") 

Transmission of pictures, maps, diagrams, etc., 
by wire. The image is scanned at the transmitter 
and reconstructed at the receiving station. 

A specified area of a record used for a particu¬ 
lar category of data; e.g., a group of card 
columns used to represent a wage rate or a set 
of bit locations in a computer word used to ex¬ 
press the address of the operand. 

A set of card columns, either fixed as to num¬ 
ber and position, or, if variable, then identifi¬ 
able by position relative to other fields. Cor¬ 
responding fields on successive cards are 
normally used to store similar information. 

A collection of related records. For example, 
in inventory control, one line of an invoice con¬ 
taining data on the material, the quantity, and 
the price forms an item; a complete invoice 
forms a record; and the complete set of such 
records forms a file. 



File Conversion 


FORTRAN 

Functional Analysis 

Functional Area 

Function, 

Processing 

Hardware 

HEDCOM 

Input 

Input, Batched 

Input, Unbatched 


A process for preparing the data base of an 
ADPS to enable the ADPS to become operational. 

In file conversion all necessary files of the data 
base are converted from their present format 
(magnetic tape, punched cards, hardcopy, etc.) 
to their required format in the ADPS about to 
become operational. 

Formula Translation; a programming language 
designed primarily for problems that can be ex¬ 
pressed in algebraic notation. The original 
version of FORTRAN has been extended to in¬ 
clude Boolean expressions, hierarchies of sub¬ 
routines sharing common storage, and insertion 
of symbolic language sequences. 

Application-oriented analysis and research re¬ 
quired to support ADPS design and implementa¬ 
tion. This effort usually takes place very early 
in the development phase and is independent of 
any particular implementation methodology. 

Any one of the broad application categories such 
as payroll, accounting, inventory control, weather 
forecasting, etc. 

A set of computer instructions performing com¬ 
putational, decisional, or data manipulation op¬ 
erations. Processing functions maybe categor¬ 
ized as input edit, sort, report generation, etc. 

The physical equipment or devices of a com¬ 
puter and peripheral equipment. 

Headquarters Command 

(1) Data supplied to a system from an external 
source for processing; (2) the process of trans¬ 
ferring data from an external to an internal 
storage. 

(1) Any set of inputs collected together as a 
group before submittal for computer processing. 
The collected groups are called batches. (2) Any 
input that is not unbatched. 

Input that is entered directly into the computer 
as it is received via an on-line input device. 
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Input Edit 

A computer processing function performed on 
input data to prepare them for the primary 
processing; e.g., limit and logic checking, 
field conversion, and data edit. 

Instruction 

An operation and the values or locations of all 
operands associated with the operation. 

Instruction, 

Multiple Address 

An instruction consisting of an operation code 
and two or more addresses. Usually specified 
as a two-address, three-address, or four- 
address instruction. 

Instruction, Object 

An instruction in the machine language of the 
computer on which the instruction is to be 
executed. 

Instruction, One 
Address 

An instruction consisting of an operation and 
exactly one address. The instruction code of 
a single address computer may include both 
zero- and multi-address instructions as spe¬ 
cial cases. 

Iso-Graph 

A planar diagram of a function of two variables, 
representing values of the function by lines of 
constant function value (iso-lines). 

Iso-Line 

A straight or curved line on an iso-graph along 
which there is a constant value. 

Language, Source 

A language in the form of written statements 
that is an input to a given translation process 
usually resulting in object instructions. 

Language, Target 

A language that is an output from a given trans¬ 
lation process. 

Library- 

(1) A collection of information available to a 
computer, usually on magnetic tapes; (2) lo¬ 
cation of the collection of magnetic tapes. 

Library, Routine 

A collection of standard proven routines and 
subroutines by which problems and parts of 
problems may be solved. 

Logical Record 

A set of logically related data fields independent 
of the physical manner of representation. 
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MAC 


MAFR 

Maintenance, 

Maintenance, 

Preventive 

Maintenance, 

Program 

Maintenance, 

Remedial 


Manager 


Merge 


MILSTAMP 


MILSTRIP 


Module 


(1) Military Airlift Command, a major Air 
Force command, formerly MATS (Military 
Air Transport Service), (2) Major Air Com¬ 
mand; any one of the Air Force commands 
such as SAC, TAC, PACAF, ATC, etc. 

Merged Accountability and Fund Reporting; 
an Air Force central accounting system. 

File A computer processing function for modifica¬ 

tion of a file to incorporate corrections, ad¬ 
ditions, and deletions. 

The maintenance of a set of hardware that at¬ 
tempts to keep equipment in top operating con¬ 
dition and to preclude failures during production 
runs. 

The process of improving, changing, and cor¬ 
recting programs of a system that is currently 
operational. 

The maintenance performed by the contractor 
following equipment failure; therefore, is per¬ 
formed as required, on an unscheduled basis. 

An individual responsible for directing and co¬ 
ordinating all or part of the activities associated 
with an ADPS. Only managers devoting at least 
10 percent of their time to a system are con¬ 
sidered part of that system 1 s personnel. 

A computer processing function that combines 
items or records from two or more sequenced 
files with the same key into one sequenced file. 

Military Standard Transportation and Movement 
Procedures; a DOD standard for worldwide ship¬ 
ment transportation activities. 

Military Standard Requisitioning and Issue Pro¬ 
cedures; a DOD standard for procurement and 
issuance of inventory items. 

(1) An interchangeable plug-in item containing 
components; (2) an incremental block of stor¬ 
age or other building block for expanding the 
computer capacity. 
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Multiplex 

The process of transferring data from several 
storage devices operating at relatively low 
transfer rates to one storage device operating 
at a high transfer rate in such a manner that the 
high-speed device is not obliged to wait for the 
low-speed devices. 

Multiprocessing 

A mode of hardware operation where two or 
more instruction sequences may be executed 
simultaneously. The instruction sequences may 
be part of the same program or different pro¬ 
grams. When the instruction sequences are 
from different programs, the hardware opera¬ 
tion is also multiprog rammed. 

Multiprogramming 

The interleaved or simultaneous execution of 
two or more programs by interconnected 
hardware. 

Off- Line 

Pertaining to peripheral equipment or devices 
not in direct communication with the central 
processing unit (CPU) of a computer. Clarified 
by 11 Equipment, Off-Line.” 

OI 

Office Instruction 

On-Line 

Pertaining to peripheral equipment or devices 
in direct communication with the central proc¬ 
essing unit (CPU) of a computer. Clarified by 
n Equipment, On-Line”; synonymous with in¬ 
line processing and on-line processing. 

Open Shop 

See n Shop, Open.” 

Operand 

A quantity entering or arising in an instruction. 
An operand may be an argument, a result, a 
parameter, or an indication of the location of 
the next instruction, as opposed to the operation 
code itself. 

Operations, 

Computer 

That part of ADP activity required for running 
production and/or development programs on 

ADP equipment. 

Operator 

(1) In the description of a process, that which 
indicates the action to be performed on operands; 

(2) a person who operates a machine. 
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Output 

(1) Those data that have been processed as an 
ultimate system product; (2) the process of 
transferring data from an internal storage to 
an external storage. 

Output, Direct 

Data produced on an on-line output device while 
the user is in attendance. 

Output, Indirect 

Data disseminated to a user via manual handling 
subsequent to its production on an output device. 

PCAM 

Punched Card Accounting Machine; the set of con¬ 
ventional punch card equipment including sorters, 
collators, and tabulators. 

PDSA 

Personnel Data System--Airmen; a centralized 
Air Force data processing system to maintain 
airman personnel data. 

PDSO 

Personnel Data System--Officers; a centralized 
Air Force data processing system to maintain 
officer personnel data. 

Preparation, 

Application 

(See "Application Preparation. 11 ) 

Programmer 

A person who prepares problem-solving pro¬ 
cedures and logical flow charts and who codes 
and debugs programs. 

Production 

Any computer processing resulting in the gen¬ 
eration of output to users. 

Production, 

Application 

(See 11 Application Production.") 

Query 

A computer processing function acting on a de¬ 
mand input which specifies that data be accessed 
via file search and be displayed or output. 

RAFT 

Regional Accounting and Finance Test; a pilot 

Air Force data processing system for testing 
a USAF base-level regional accounting and fi¬ 
nance system concept. 

Ratio, Operating 

The ratio of the number of hours of correct ma¬ 
chine operation to the total hours of scheduled 
operation; e.g., on a 1 68-hour-week scheduled 
operation, if 12 hours of preventive maintenance 
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Real-Time 

are required and 4.8 hours of unscheduled 
downtime occurs, then the operating ratio is 
(168 - 16.8) /168, which is equivalent to a 

90 percent operating ratio. 

(1) Pertaining to the actual time during which a 
physical process transpires; (2) pertaining to 
the performance of a computation during the 
actual time that the related physical process 
transpires so that results of the computations 
can be used in guiding the physical process. 

Record 

(1) A group of related fields of information 
treated as a unit; (2) to put data into a storage 
device. 

Record, Unit 

A separate record that is similar in form and 
content to other records; e.g., a summary of 
a particular employee's earnings to date. 

Reliability 

(1) A measure of the ability to function without 
failure; (2) the amount of credence placed in a 
result. 

Relocate 

In programming, to move a routine from one 
portion of storage to another and to adjust the 
necessary address references so that the rou¬ 
tine can be executed in its new location. 

Report Generation 

A computer processing function that transforms 
results from the primary computation to outputs 
for the system user; e.g., data edit, formatting, 
and printing. 

Response 

The response of a device or system is a quanti¬ 
tative expression of the output as a function of 
the input under conditions that must be ex¬ 
plicitly stated. 

Routine 

A set of coded instructions arranged in proper 
sequence to direct the computer to perform a 
desired operation or sequence of operations. 

A subdivision of a program consisting of two 
or more instructions that are functionally re¬ 
lated; therefore, a program. 

Routine, Debugging 
Aid 

A routine to aid programmers in the debugging 
of their routines. Some typical routines are 
storage printout, tape printout, and drum print¬ 
out routines. 


177 






Routine, Executive 

A routine that controls loading and relocation 
of routines and in some cases makes use of 
instructions that are unknown to the general 
programmer. Effectively, an executive routine 
is part of the machine itself. 

Routine, Service 

A broad class of routines that are standardized 
at a particular installation for the purpose of 
assisting in maintenance and operation of the 
computer as well as in the preparation of pro¬ 
grams, as opposed to routines for the actual 
solution of production problems. This class 
includes monitoring or supervisory routines, 
assemblers, compilers, diagnostics for com¬ 
puter malfunctions, simulation of peripheral 
equipment, general diagnostics, and input data. 
The distinguishing quality of service routines 
is that they are generally standardized to meet 
the servicing needs at a particular installation, 
independent of any specific production-type rou¬ 
tine requiring such services. 

Routine, Utility 

A standard routine used to assist in the operation 
of the computer; e.g., a conversion routine, a 
sorting routine, a printout routine, or a tracing 
routine. Synonymous with utility program. 

Run 

The performance of one or more programs on 
a computer; thus, the performance of one rou¬ 
tine or several routines linked so that they form 
an automatic operating unit, during which manual 
manipulations by the computer operator are zero, 
or at least minimal. 

SAC 

Strategic Air Command 

Shop, Closed 

The operation of a computer facility where pro¬ 
gramming service to the user is the responsi¬ 
bility of a group of specialists, thereby effec¬ 
tively separating the phase of task formation 
from that of computer implementation. The pro¬ 
grammers are not allowed in the computer room 
to run or oversee the running of their programs. 
Contrasted with "Shop, Open. 11 

Shop, Open 

The operation of a computer facility where com¬ 
puter programming, coding, and operating can 
be performed by any qualified employee of the 
organization, not necessarily by the personnel 






Software 

of the computing center itself; and where the 
programmer may assist in or oversee the run¬ 
ning of his program on the computer. Contrasted 
with "Shop, Closed." 

The totality of programs and routines used to 
extend the capabilities of computers, such as 
compilers, assemblers, narrators, routines, 
and subroutines. Contrasted with "Hardware." 

Sort 

(1) To arrange items of information according 
to rules dependent upon a key or field contained 
in the items or records; (2) a computer proc¬ 
essing function to arrange records of informa¬ 
tion according to rules operating upon key(s) 
contained in the records. 

Statement, Source 

In computer programming, a meaningful ex¬ 
pression or generalized instruction in a source 
language. 

Storage, Auxiliary 

A storage device in addition to the main storage 
of a computer; e.g., magnetic tape, disk, or 
magnetic drum. Auxiliary storage usually holds 
much larger amounts of information than the 
main storage, and the information is less rap¬ 
idly accessible. 

Storage, Main 

Usually the fastest storage device of a computer 
and the one from which instructions are executed. 

System, Automatic 
Data Processing 

The term descriptive of an interacting assembly 
of procedures, processes, methods, personnel, 
and automatic data processing equipment which 
performs a complex series of data processing 
operations. 

System Analyst 

A person skilled in the definition and development 
of techniques for solving a problem. System ana¬ 
lysts are usually specialists in a particular class 
of problems such as inventory, accounting, com¬ 
mand and control, etc. 

TAC 

Tactical Air Command 

Terminal 

(1) A point in a system or communication net¬ 
work at which data can either enter or leave; 

(2) a general term referring to the equipment 
at the end of a telegraph circuit; modems and 
associated equipment. 
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Test, Program 

A system of checking before running any prob¬ 
lem in which a sample problem of the same type 
with a known answer is run. 

Test, System 

(1) The running of the whole system against 
test data; (2) a complete simulation of the 
actual running system for purposes of testing 
the adequacy of the system; (3) a test of an 
entire interconnected set of components for 
the purpose of determining proper functioning 
and interconnection. 

Throughput 

Productivity based on all facets of an operation. 
For example, a computer with a capability of 
simultaneous operations (e.g., read/write/ 
compute) would have a high throughput rating. 

Time, Application 
Preparation 

Any computer processing involved in initial file 
development and other one-time operations when 
converting an application, including parallel 
operations. 

Time, Application 
Production 

Any computer processing of an application re¬ 
sulting in the generation of output to the applica¬ 
tion user(s). 

Time, Available 

(1) The number of hours a computer is available 
for use; (2) the time during which a computer 
has the power turned on, is not under mainte¬ 
nance, and is known or believed to be operating 
correctly. 

Time, Chargeable 
Lost 

This time may be attributed to the following: 

(a) Programming Error: Rerun time as a re¬ 
sult of program errors, (b) Operator Error: 
Rerun time as a result of computer operator 
errors, (c) Defective Tape: Rerun time as a 
result of magnetic tape defects when such time 
is not gratuitously provided, (d) Scheduling 

Error: Rerun time when a program run is proc¬ 
essed out of sequence with incomplete data, 
etc., because of an erroneous schedule, (e) De¬ 
fective Materials: Rerun time due to material 
defects other than magnetic tape; i.e. , bad paper, 
card defects, poor printer ribbons, etc. (f) In¬ 
correct Data: Rerun time caused by erroneous 
input data received from another organization 
or other data, (g) Site Environment Failures: 
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Time, Down 


Time, Idle 


Time, Machine 
Error Lost 

T ime, Off 


Time, Operational 
Use 


T ime, Othe r 


Time, Program 
Development and 
Maintenance 


Time, Program 
Testing 


Rerun time caused by an air conditioning failure, 
electric power failure, or other site phenomenon 
that interrupts processing, (h) Other Chargeable 
Rerun: Rerun time caused by factors other than 
above. 

The period during which a computer is malfunc¬ 
tioning or not operating correctly because of 
mechanical or electronic failure, as opposed to 
available time, idle time, or standby time, dur¬ 
ing which the computer is functional. Contrasted 
with "Time, Up." 

That time, scheduled or unscheduled, which nor¬ 
mally occurs between completing of one program 
run (end of tear down) and starting to set up for 
the next program run. Idle time may also occur 
during a run period. Idle time also includes that 
portion of time the computer system cannot be 
used because of site environment failure. 

Rerun time provided by the vendor as a result 
of computer system failure. 

Time when the computer system is not scheduled 
to operate. (Usually occurs on weekends, holi¬ 
days, and late evening or early morning hpurs.) 

In Federal Government ADP contracts, the time 
during which the equipment is in operation, ex¬ 
clusive of idle time, setup time, maintenance 
time, or rerun time due to machine failure. 
Components not programmed for use in a spe¬ 
cific computer run are not considered to be in 
use, even though connected into the computer 
system. 

Time when no other classification of time is 
applicable or when the classification of time 
is not available or unknown. 

The computer time for chargeable program de¬ 
velopment and maintenance, including assembly, 
compilation, test, and maintenance. (Mainte¬ 
nance refers to time spent in changing, improv¬ 
ing, and patching of existing programs.) 

The machine time expended for program testing, 
debugging, and volume and compatibility testing. 
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Time, Search 

The time required to locate a particular field 
of data in storage. Searching requires a com¬ 
parison of each field with a predetermined 
standard until an identity is obtained. This is 
contrasted with access time, which is based on 
locating data by means of the address of its stor¬ 
age location. 

Time, Scheduled 
Maintenance 

Time during which the computer system is placed 
at the disposal of the engineer for scheduled pre¬ 
ventive maintenance and during which maintenance 
is actually performed. 

Time, Setup 

Time required to load and unload tape drives 
and card readers, to insert printer forms, etc., 
when the CPU is not processing. Such time may 
occur at the beginning of, during, or at the end 
of, a processing run and includes temporary de¬ 
lays, such as correcting card and paper jams. 

Time-Sharing 

(1) The use of a device for two or more pur¬ 
poses during the same overall interval, accom¬ 
plished by interspersing component actions in 
time; (2) pertaining to the interleaved use of the 
time of a device. 

Time, System 
Improvement 

The machine downtime needed for the installation 
and testing of new components, large or small, 
and machine downtime necessary for modifica¬ 
tion of existing components. This includes ail 
programmed tests following the above actions to 
prove the machine is operating properly. 

Time, Turnaround 

The average time required by a computer opera¬ 
tions unit to complete a program compilation or 
test, including time waiting in queue of jobs to 
be run. 

Time, Unscheduled 
Maintenance 

Time during which the computer system is down 
due to a machine malfunction. The computer 
system is considered down when it is not used 
because one or more components are down. Re¬ 
medial maintenance is performed during this time. 

Time, Up 

The time during which equipment is either pro¬ 
ducing work or is available for productive work. 

T race 

An interpretive diagnostic technique that provides 
an analysis of each executed instruction. 


182 







Transport, Tape 

The mechanism that moves magnetic or paper 
tape past sensing and recording heads; usually 
associated with data processing equipment. 
Sometimes called tape drive. 

Update 

To put into a file changes required by current 
information or transactions. 

USAF 

United States Air Force 

Workload 

The external aspects of information flow asso¬ 
ciated with an ADPS. Workload is broken into 
the following major areas: inputs, outputs, 
data base, and processing functions. Each 
major area is further broken into components 
such as input volume, output volume, and data 
base size. 

Workload Descriptor 

A measurable numeric quantity defining the mag 
nitude of workload components such as input 
volume, output variety, and data base size. 
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B. 


Glossary of Cost Factors and Workload Descriptors 


Average Number of Years 
of ADP Experience for 
Analysts 


Average Number of Years 
of ADP Experience for 
Development Managers 

Average Number of Years 
of ADP Experience for 
Operations Personnel 


Average Number of Years 
of ADP Experience for 
P r og ramme r s 


Average number of Years 
of College Education for 
Development Managers 


Average Number of Years 
of Functional Area Ex¬ 
perience for Analysts 


Average number of years in ADP for ana¬ 
lysts, who are persons skilled in the def¬ 
inition and development of techniques for 
solving a problem. 

Average number of years in the field of 
automatic data processing (ADP) for de¬ 
velopment managers. 

Average number of years in ADP for op¬ 
erations personnel, including operators, 
schedulers, data edit personnel, magnetic 
type librarians, report binders, and 
managers. 

Average number of years in ADP for pro¬ 
grammers, who are persons who prepare 
problem-solving procedures and logical 
flow charts, and code and debug programs. 

Development managers' college education, 
measured in average number of years, 
where development managers are the in¬ 
dividuals responsible for directing and 
coordinating all or part of the activities 
associated with an ADPS during the de¬ 
velopment phase. Only managers devot¬ 
ing at least 10 percent of their time to the 
system are considered. 

Average number of years of experience in 
a field of application for analysts, who are 
persons skilled in the definition and develop¬ 
ment of techniques for solving a problem. 


Average Number of Years 
of Functional Area Expe¬ 
rience for Development 
Managers 


Average number of years of experience in 
a field of application such as accounting, 
inventory control, weather forecasting, 
etc., for development managers, where 
development managers are the individuals 
responsible for directing and coordinating 
all or part of the activities associated with 
an ADPS during the development phase. 
Only managers devoting at least 10 percent 
of their time to the system are considered. 
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Average Number of Years 
of Functional Area Expe¬ 
rience for Operations 
Personnel 

Average number of years of experience in 
a field of application for operations person¬ 
nel, including operators, schedulers, data 
edit personnel, magnetic tape librarians, 
report binders, and managers. 

Average Number of Years 
of Functional Area Expe¬ 
rience for Programmers 

Average number of years of experience in 
a field of application for programmers, who 
are persons who prepare problem-solving 
procedures and flow charts, and code and 
debug programs. 

Characters in Data Base 

The expected number of characters in the 
data base where the data base is a collec¬ 
tion of files that contain unique informa¬ 
tion, are accessible to the ADPS, and are 
normally referenced or updated with rela¬ 
tively high frequency. Intermediate files 
are not counted. 

Characters Per Month 
of Input Volume 

The expected amount of ADPS input orig¬ 
inating outside the ADPS, measured in 
characters per month. Intermediate in¬ 
puts of the ADPS should not be included. 

On unit record input, only character posi¬ 
tions used for data are counted. 

Characters Per Month 
of Output Volume 

The expected amount of ADPS output des¬ 
tined to users, measured in characters 
per month. Intermediate outputs of the 
ADPS are not included. Only nonblank 
characters are counted. 

Dollars of Hardware Cost 
for Program Checkout 

The hardware cost for computer hours 
used for program checkout during the de¬ 
velopment phase of the ADPS. 

Dollars Per Month of 
Hardware Cost for 
Application Production 

The hardware cost for monthly computer 
hours charged to the user of the ADPS for 
processing that is not of a developmental 
or corrective nature. 

Dollars Per Month of 
Hardware Cost for 

Program Maintenance 

The hardware cost for the monthly com¬ 
puter hours used for processing improve¬ 
ments, changes, and corrections to pro¬ 
grams of an operational ADPS. 
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Man-Months of 
Development Effort 


Months of Elapsed 
Development Time 


The number of man-months expended by all 
relevant personnel, including managers, 
analysts, programmers, and operators, to 
develop the ADPS during the development 
phase, which begins with the start of sys¬ 
tem design and ends when the system is 
declared operational. During this develop¬ 
ment phase such activities as detailed sys¬ 
tem design, programming, checkout, and 
equipment installation are accomplished. 

The number of calendar months elapsed 
from the date system design for the ADPS 
is begun to the date it is declared operational. 


Number of Data 
Base Record Types 


Number of Input 
Data Fields 


Number of Input 
Transaction Types 


Number of Object 
Instructions 


Number of Output 
F or mats 

Number of Operations 
Personnel 


Number of Program 
Maintenance Personnel 


The number of logical record types in the 
data base where a logical record is a set 
of logically related data fields independent 
of the physical manner of storage. 

A count of data fields from the ADPS input 
that are unique in content and/or format; 
e. g. , if there is a data field for name on 
six different card formats, the number of 
unique data fields is one. 

A count of different transaction types of 
ADPS input that normally are identified 
by a unique transaction code and/or a 
unique input format. 

The number of instructions generated by 
the compiler or assembler for the ADPS. 
This is the number of machine-format in¬ 
structions in an object program deck that 
can be processed directly by the computer. 

The number of different types and formats 
of ADPS outputs. 

The number of personnel, including op¬ 
erators, schedulers, data edit personnel, 
magnetic tape librarians, report binders, 
and managers, etc., used to process the 
ADPS programs on the computer during 
the operations phase. 

The number of personnel, including man¬ 
agers, analysts, and programmers, in¬ 
volved in improving, changing, and cor¬ 
recting programs of a system during the 
operations phase. 
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Number of Source 
Statements 

The number of lines of code written by the 
programmer in any source language for the 

ADPS. This may be the same as the num¬ 
ber of instructions in machine language. 

Percent of Input 

Rejects 

Input data error rate, measured by the 
ratio of the number of rejected records 
to the number of expected records per 
month multiplied by 100. 

Percent of Production 
Hours for Compute 

The percent of production hours per month 
for compute, where compute is the per¬ 
formance of logical, arithmetic, and de¬ 
cisional operations on data. 

Percent of Production 
Hours for Control 

The percent of production hours per month 
for control, where control is a computer 
processing function that expedites all other 
computer processing functions; e.g., job 
scheduling, priority handling, segment 
overlaying, data management, and hard¬ 
ware assignment, etc. 

Percent of Production 
Hours for File 
Maintenance 

The percent of production computer hours 
per month for file maintenance, where file 
maintenance is the modification of a file to 
incorporate corrections, additions, and 
deletions. 

Percent of Production 
Hours for Input Edit 

The percent of production computer hours 
per month for input edit, where input edit 
is performed on input data to prepare it 
for the primary processing; e.g., limit 
and logic checking, field conversion, and 
data edit. 

Percent of Production 
Hours for Merge 

The percent of production computer hours 
per month for merge, where merge is the 
combining of items or records from two 
or more sequenced files with the same 
key into one sequenced file. 

Percent of Production 
Hours for Query 

The percent of production hours per month 
for query, where query is action on a de¬ 
mand input which specifies that data be 
accessed via file search and displayed or 
output. 

Percent of Production 
Hours for Report 
Generation 

The percent of production computer hours 
per month for report generation, where 
report generation is the transformation 
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of results from primary computations to 
outputs for the system user. 


Percent of Production 

Hours for Sort 

The percent of production hours per month 
for sort, where sort is the arranging of 
records of information according to rules 
operating upon key(s) contained in the 
records. 

Percent of Source State¬ 
ments for Compute 

The percent of source statements for com¬ 
pute, where compute is the performance 
of logical, arithmetic, and decisional op¬ 
erations on data. 

Percent of Source State¬ 
ments for Control 

The percent of source statements for con¬ 
trol, where control is a computer process¬ 
ing function that expedites all other com¬ 
puter processing functions; e.g., job 
scheduling, priority handling, segment 
overlaying, data management, and hard¬ 
ware assignment. 

Percent of Source State¬ 
ments for File Maintenance 

The percent of source statements for file 
maintenance, where file maintenance is 
the modification of a file to incorporate 
corrections, additions, and deletions. 

Percent of Source State¬ 
ments for Input Edit 

The percent of source statements for input 
edit, where input edit is performed on input 
data to prepare it for the primary process¬ 
ing; e. g. , limit and logic checking, field 
conversion, and data edit. 

Percent of Source State¬ 
ments for Merge 

The percent of source statements for merge, 
where merge is the combining of items or 
records from two or more sequenced files 
with the same key into one sequenced file. 

Percent of Source State¬ 
ments for Query 

The percent of source statements for query, 
where query is action on a demand input 
which specifies that data be accessed via 
file search and displayed or output. 

Percent of Source State¬ 
ments for Report 

Generation 

The percent of source statements for re¬ 
port generation, where report generation 
is the transformation of results from pri¬ 
mary computations to outputs for the sys¬ 
tem user. 
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Percent of Source 
Statements for Sort 


The percent of source statements for sort, 
where sort is the arranging of records of 
information according to rules operating 
upon key(s) contained in the record. 
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Use of the Development Experience Index 

The development experience index is used to retrieve relevant 
development experience from the system descriptions. Retrieval 
is based on the following workload descriptors: 

Number of Input Transaction Types 
Number of Input Data Fields 
Number of Output Formats 
Number of Data Base Record Types 

Proposed values of these workload descriptors must be known for 
the ADPS under evaluation. The type of development experience 
and problems retrieved by this index will be related to the magni¬ 
tude of the development effort. Sections of system descriptions 
which will be of greatest interest include: 

Application Program Development 
Application Program Maintenance 

Other sections of interest include: 


Schedule 


Organization 

History 

Software 


File Conversion 

Documentation 

Personnel 


Benefits 
Cost Factors 
Description 


Procedure 

1. Enter the proposed values for No. of Input Transaction Types, No. of Input Data Fields, No. of Output 
Formats, and No. of Data Base Record Types in box below the corresponding scale. 

2. Remove the index card from the pocket in the Air Force ADP Experience Handbook (Pilot Version) and posi¬ 
tion the center arrow of the Development Slide at the proposed value on the No. of Input Transaction Types scale. 

3. For all systems bounded by the Development Slide, enter the number from the tolerance band in the 
No. of Input Transaction Types row of the Ranking Table beneath the corresponding system name. 

4. Repeat steps 2 and 3 for No. of Input Data Fields, and No. of Output Formats. 

5. Repeat steps 2 and 3 for No. of Data Base Record Types if the proposed value is not zero. If the pro¬ 
posed No. of Data Base Record Types is zero, enter the number 3 in the Data Base row of the Rank¬ 
ing Table beneath ADOBE, MISSIM, and ORBIT. 

6. Enter the Total Rank in the bottom row of the Ranking Table. Total Rank is computed by adding the 
numeric entries in each each column of the Ranking Table. 

7. The system with the largest Total Rank is the most relevant system in developmental aspects to the 
proposed system. Relevancy of other systems is in order of Total Rank. Systems with Total Rank 
equal to or greater than 7 are highly relevant to the proposed automation. Systems with Total Rank 
less than 7 but greater than 3 have less relevance, but may still be used, while developmental experi¬ 
ence data from systems with Total Rank less than or equal to 3 should not be used. 
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Use of the Operations Experience Index 

The operations experience index is used to retrieve relevant operations 
experience from the system descriptions. Retrieval is based on the 
following workload descriptors: 

Char./Mo. of Input Volume 
Char. /Mo. of Output Volume 
Char, in Data Base 

Proposed values of these workload descriptors must be known for the 
ADPS under evaluation. The type of operations experience and prob¬ 
lems retrieved by this index will be related to the magnitude of the op¬ 
erations. Sections of the system descriptions which will be of greatest 
interest include: 

Operations 

Hardware 

Other sections of interest include: 


Organization 

Software 

File Conversion 


Documentation 

Personnel 

Benefits 


Cost Factors 
Description 


Procedure 

1. Enter the proposed values for Char. /Mo. of Input Volume, Char. /Mo. of Output Volume, and Char, 
in Data Base in the box below the corresponding scale. 

2. Remove the index card from the pocket in the Air Force ADP Experience Handbook (Pilot Version) and posi¬ 
tion the center arrow of the Operations Slide at the proposed value of the Char. /Mo of Input Volume scale. 

3. For all systems bounded by the Operations Slide, enter the number from the tolerance band in the 
Char. /Mo. of Input Volume row of the Ranking Table beneath the corresponding system name. 

4. Repeat steps 2 and 3 for Char. /Mo. of Output Volume. 

5. Repeat steps 2 and 3 for Char, in Data Base, if the proposed value is not zero. If the proposed 
Char, in Data Base is zero, enter the number 3 in the Data Base row of the Ranking Table beneath 
ADOBE, M1SSIM, and ORBIT. 

6. Enter the Total Rank in the bottom row of the Ranking Table. Total Rank is computed by adding the 
numeric entries in each column of the Ranking Table. 

7. The system with the largest Total Rank is the most relevant system in operational aspects to the 
proposed system. Relevancy of other systems is in order of Total Rank. Systems with Total 
Rank equal to or greater than 5 are highly relevant to the proposed system. Systems with Total 
Rank less than 5 but greater than 2 have less relevance, but may still be used, while operational 
experience data from systems with Total Rank less than or equal to 2 should not be used. 


Ranking Table 
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c. 


Functional Area Index 


Page Number 

O' 

CO 
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H 
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tM 
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CO 
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co 
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in 
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00 

in 
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\ System 

Functional \ 
Area \ 

ADOBE 

AMPS 

DSWC 

GE/BSS 

GWC 

MAFR 

MILSTAMP 

MISSIM 

ORBIT 

u 

c 

a 

PDSO/MAC 

PDSO/MPC 

RAFT 

RRC 

SC/ACCT 

SPCTRK 

TCC 

1050/BSS 

Operations 

Supporting 
















X 

X 


Research and 
Development 

X 







X 

X 










Materiel 

Management 




X 






X 




X 




X 

Personnel/ 

Manpower 











X 

X 







Financial and 
Accounting 


X 




X 







X 


X 




Weather 





X 












• 


T ransportation 
Management 







X 












Miscellaneous 



X 

















Use : To use this index, find the row of the Functional Area Index 
Table with the same functional area as the proposed ADPS. Systems se¬ 
lected with the same functional area as the proposed ADPS are designated 
by an "X" in this row under the system acronym. System description 
sections of the selected systems of greatest interest are 

Function 

Description 

Other system description sections of interest are 

Application Program Development 

File Conversion 

Personnel 

Application Program Maintenance 
Benefits 
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D. Decentralized Operations Index 


Page Number 
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LO 
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158 

\ System 

Number oi\ 
Installations 

ADOBE 

AMPS 

DSWC 

GE/BSS 

GWC 

MAFR 

MILS TAMP 

MISSIM 

ORBIT 

PDS 

PDSO/MAC 

PDSO/MPC 

RAFT 

RRC 

SC/ACCT 

SPCTRK 

TCC 

1050/BSS 

Single 

Installation 

X 




X 

X 

X 

X 

X 



X 

X 



X 

X 


2 to 7 

Installations 




X 






X 




X 





8 to 100 
Installations 



X 








X 




X 




More than 100 
Installations 


X 
















X 


Use : To use this index, find the row of the Decentralized 
Operations Index Table corresponding to the number of operational 
installations for the proposed ADPS. Systems selected with the number 
of operational installations in the same range as the proposed ADPS are 
designated by an n X n in this row under the system acronym. System 
description sections of the selected systems of greatest interest are 

Location 

History 

Schedule 

Application Program Development 
Application Program Maintenance 

Other system description sections of interest are 

Organization 

Description 

Hardware 

Documentation 

Personnel 

Benefits 

Cost Factors 
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E. 


Multiple Application Index 
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Number 01 V 
Applications \ 

ADOBE 
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GE/BSS 

o 

£ 

o 
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MILSTAMP 

MIS SIM 

ORBIT 

1 1 
1 1 

PDSO/MAC 

PDSO/MPC 

RAFT 

RRC 

SC/ACCT 

SPCTRK 

TCC 

1050/BSS 

Single 

Application 


X 


X 






• 

J. k 


X 




X 

X 

X 

2 to 10 
Applications 





X 

X 

X 






X 






More than 10 
Applications 

X 


X 





X 

X 


X 



X 

X 





Use: To use this index, find the row of 1 he Multiple Applications 
Index Table corresponding to the number of ap >lications at an installation 
for the proposed ADPS. Systems selected witl the number of applica¬ 
tions in the same range as the proposed ADPS are designated by an M X n 
in this row under the system acronym. The s^ stem description section 
of the selected systems of greatest interest is 

Operations 

Other system description sections of interest ; re 

Organization 

Software 
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F. 


Programming Language 
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n. System 

Languages'x 
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MISSIM 
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PDS 

PDSO/MAC 

PDSO/MPC 

RAFT 
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SPCTRK 
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1050/BSS 

COBOL 






X 

X 




X 

X 

X 






FORTRAN 

X 




X 



X 

X 







X 



ALGOL 












X 







ALTAC 
















X 



Autocoder 



X 











X 

X 


X 


GAP 




X 















FAP 





X 



X 

X 










ARGUS 











X 








RCA Assembly 
Language 










X 









TAC 
















X 



PAL 

















X 


Machine 

Language 


X 


















Use : To use this index, find the row of Programming Language 
Index Table with the same programming language specified for the 
proposed ADPS. Systems selected with the same programming language 
as the proposed ADPS are designated by an "X 11 in this row under the 
system acronym. The system description sections of the selected 
systems of greatest interest are 

Software 

Application Program Development 
Application Program Maintenance 

Other system description sections of interest are 

Description 

Hardware 

Personnel 

Benefits 
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G. 


Processing Type Index 
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X 

X 
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Processing 




X 








X 



X 


X 

X 

Batched Under 
Executive 

Control 

X 


X 

X 

X 

X 

X 

X 

X 


X 

X 

X 

X 

X 

X 

X 

X 

Batched With 
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X 


















Use: To use this index, find the row of :he Processing Type Index 
Table corresponding to the processing type of the proposed ADPS. 
Systems selected with the same type of processing as the proposed ADPS 
are designated by an "X" in this row under the system acronym. System 
description sections of the selected systems o ' greatest interest are 

Description 

Hardware 

Software 

Other system description sections of interest ire 
Workload 

Application Program Development 

Operations 

Cost Factors 


201 








































H. 


File Conversion Index 
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Type of FileN. 
Conversion N. 
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ORBIT 
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PDSO/MAC 

PDSO/MPC 
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SC/ACCT 

SPCTRK 
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No. File 
Conversion 

X 




X 


X 

X 

X 

X 




X 





Manual to 

ADP System 


X 

X 










X 


X 



X 

PC AM to 

ADP System 















X 



X 

ADP System 
to ADP System 




X 


X 





X 

X 




X 

X 

X 


Use; To use this index, find the row of the File Conversion Index 
Table corresponding to the type of file conversion for the proposed ADPS. 
Systems selected with the same type of file conversion as the proposed 
ADPS are designated by an "X" in this row under the system acronym. 
The system description section of the selected systems of greatest 
interest is 


File Conversion 

Other system description sections of interest are 

History 
Schedule 
Workload 
Hardware 
Cost Factors 
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I. Direct Access Storage Index 
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1 to 10M Char. 
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X 

X 

10M to 50M 

Char. 




X 















Greater than 

50M Char. 










> 


X 








Use: To use this index, find the row of tie Direct Access Storage 
Index Table corresponding to the amount of dir set access storage for the 
proposed ADPS. Systems selected with amoun of direct access storage 
in the same range as the proposed ADPS are d< signated by an "X" in this 
row under the system acronym. The system d sscription section of the 
selected systems of greatest interest is 

Hardware 

Other system description sections of interest are 

Description 

Software 

Application Program Development 
Operations 

Application Program Maintenance 


203 





































(continued on next page) 

204 


7,330 

7,490 

7, 615 

8, 130 
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Use: To use this index, find the row of tie Computer Cost Index 
Table with closest basic monthly rental of an individual computer in the 
proposed ADPS. Systems selected are designs ted by an "X" in this row 
under the system acronym. System descriptio is sections of the selected 
systems of greatest interest are 

Hardware 

Operations 

Other system description sections of interest ere 

History 
Schedule 
Workload 
Software 
Cost Factors 
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Use; To use this index, find the row of he Computer Index Table 
with the same computer as the proposed ADPS, Systems selected using 
the same computer as the proposed ADPS are designated by an "X" in 
this row under the system acronym. System c escription sections of the 
selected systems of greatest interest are 

Hardware 

Operations 

Other system description sections of interest ire 

History 

Schedule 

Workload 

Software 

Application Program Development 
File Conversion 

Application Program Maintenance 
Cost Factors 
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Use : To use this index find the row of the Security Index Table 
with the same security classification as the proposed ADPS. Systems 
selected with the same security classification as the proposed ADPS are 
designated by an f, X M in this row under the system acronym. System 
description sections of the selected systems of greatest interest are 

Organization 

Operations 

Other system description sections of interest are 

History 

Description 

Hardware 

Application Program Development 

File Conversion 

Documentation 
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